What does "SET" do

[gemma-the-husky]

Doc.

Yes, post a link if you like but there is already something on this site which might help:-

http://www.access-programmers.co.uk/forums/showthread.php?t=225415

There is even a demo for people to test. And on my SkyDrive site there are plenty more demos which use pointers to other Objects, all the OpenArgs demos.

----------

But you were also talking about the need to close recordsets and set them to Nothing. While under some circumstances that might be necessary it generally isn’t.

We can all post links to people who say it is necessary and some of us can post links to people who say it isn’t necessary. So what I was wondering about is if you could prove that it is necessary via a posted demonstration database.

----------

But about the use of the word Set. Your post restates that it is required. Well, it is required sometimes but not all. So the question was; why does the compiler require it sometimes but not all?

Chris.

Chris. Releasing memory using set obj = nothing
I think this example is correct. hopefully it is testable.

not a recordset, but releasing memory used by an object.

I have code that iterates all my forms to make design amendments - eg, change the form background to a standard setting

dim frm as form
dim obj as object
 
for each obj in currentproject.allforms
'it seems to be an object, not a form, so you have to do this in 2 steps
 
     DoCmd.OpenForm obj.Name, acDesign
[COLOR=blue]     Set frm = Forms(obj.Name)[/COLOR]
 
     make changes
 
     DoCmd.Close acForm, frm.Name, acSaveYes
[COLOR=red]     Set frm = Nothing [/COLOR]
     DoEvents 'tidies up the display
next

I thought the statement in blue would just reassign the frm variable each time - but it doesn't seem to release the memory unless I explicitly include the red line as well.

if I do not have the set frm = nothing statement, then eventually the programme crashes with an out of memory error, whereas if I do have it, it does the lot.

We are talking about a biggish application with several hundred forms, and I presume it is also dependent on the amount of memory actually available.

I was processing my forms in batches of 50 or so, until I realised that releasing the memory seemed to make a difference.

-----

with regard to forcing the use of the keyword SET. The "why" must just be the way the compiler is written. If some particular examples of using objects do not require set - then it must just be because the compiler writers didn't force the keyword to be required in certain instances. ie the compiler can generate the p-code, or assembler code without needing the token "SET" in some instances. (my terminology is probably incorrect, but I am sure the thought process is valid)

a compiler is just another program after all, is it not?

 

[ChrisO]

Dave.

Because it is hearsay, I will not require anyone to believe this. I can test that code with 41 Forms and there was no memory creepage without the Set to Nothing. I can run it continuously and still get no out of memory. I can’t test it any other way but that is the result I get, no continuous increase in memory. So there is still no reproducible proof.

But that is beside the point; it has nothing to do with having to close recordsets and setting their pointers to Nothing.

Did you get a chance to read the link I posted in post #21 and did you come to some conclusion about it?

Chris.

 

[jdraw]

For what it may be worth, I found this M$oft reference using Google
http://office.microsoft.com/en-us/access-help/HV080756549.aspx

 

[ChrisO]

Well, that’s one of the problems with posting links without testing.

That document is already in Access help available using the F1 key on Object.
The url says Access-help but it is VB help not VBA help.
The code is in error for VBA with Access.

Yet people might say “I read it on a Microsoft site so it must be correct.”

-----------

The document says how to use Set; it does not say why we need to use Set.

-----------

It does say:
“If objectvar contained a reference to an object, that reference is released when the new one is assigned.”

-----------

It does say:
“Assigning Nothing to objectvar releases all the system and memory resources associated with the previously referenced object when no other variable refers to it.”

But it does not say that Nothing must be assigned to objectvar in order to release memory resources. For example: objectvar may simply go out of scope and release memory resources without assigning Nothing to it.

-----------

Any link without the ability to test it becomes a doubtful proposition.

Chris.

 

[gemma-the-husky]

Dave.

Because it is hearsay, I will not require anyone to believe this. I can test that code with 41 Forms and there was no memory creepage without the Set to Nothing. I can run it continuously and still get no out of memory. I can’t test it any other way but that is the result I get, no continuous increase in memory. So there is still no reproducible proof.

But that is beside the point; it has nothing to do with having to close recordsets and setting their pointers to Nothing.

Did you get a chance to read the link I posted in post #21 and did you come to some conclusion about it?

Chris.

thanks for investigating. to be honest, i wasn't 100% sure about the exact circumstances which causing my problem. I just wanted to get the forms fixed. I thought it was related to releasing memory, but it may not have been.

----

i take it your link (#21) was to your interesting thread about objects/pointers.

In other languages, I can design a structure as follows. note that I use the words "object" and "collection" in the general sense, and not as the vba structures.

structure:
a collection of data (ie an object)
pointer1 (to another similar structure)
pointer2 (to another similar structure)
etc

I can then manage a collection of objects, by manipulating the pointers in each structure. so (eg) pointer 1 points to the previous item. pointer 2 points to the next item.

i then have (perhaps) two other pointers
headpointer - pointing to the (logical) start of the collection
cursorpointer - pointing to the active item in the collection

i can then define a series of actions to manipulate this collection.
find/insert/delete etc. all done by following and manipulating the pointer chain.

by manipulating the pointers in particular ways, i can define a queue, a linked list, a doubly linked list, a tree etc etc.

(the vba collection type offers a very limited subset of such general functionality)

----

so you seem to be indicating that despite vba not having a "pointer" data type that can be manipulated directly, you can still achieve this "pointer" functionality by using other techniques to manipulate the memory.

Before I spend a lot of time investigating your code, can you just confirm that I am on the right track?

many thanks

 

[ChrisO]

Dave.

No, I mean the link in post #21.

Chris.

 

[jdraw]

Here is a quote from Function X vba Set operator

Set

We saw earlier that you could declare a variable based on a built-in object of VBA. To specify the particular object you are referring to, you can (must) use the Set operator to assign an existing object to your variable. This would be done as follows:

dim ctlFirstName as Control
Set ctlFirstName = TextBox

Function X is considered an excellent source or tutorials -- Access, vba...

I was unable to find other sources of info specific to the Set operator, although I'm sure they do exist. This is as close to why you'd use SET that I found.

With Access 97 and 2000 the consensus of "knowledgeable users" -- those we all looked up to as "experts/experienced" folks-- was to always set an Object to Nothing. The argument as I recall was - you must free up memory. This was just considered good practice - much like naming conventions, comments, etc.

As Chris has said, the requirement that you MUST set an object variable to Nothing, seems to have been released/relaxed. Perhaps it never was mandatory.

 

[Galaxiom]

This was just considered good practice - much like naming conventions, comments, etc.

As Chris has said, the requirement that you MUST set an object variable to Nothing, seems to have been released/relaxed. Perhaps it never was mandatory.

Much like Hungarian Notion naming conventions which are hangovers from a time when VB script was the norm and variables could not be typed.

Comments are still a good thing but I prefer none to code that is so littered with them that the actual code is hard to see.

My favourite comment style with naming convention:

'Initialize Start Date variable as date
Dim dteStartDate As Date

 

[ChrisO]

Galaxiom.

By now I think everyone knows of your dislike for Hungarian Notion.
And some comments in code can be just ridiculous.
Both deserve their own place in the Sun, but also could be a distraction from this thread.

-----------

jdraw.

>>As Chris has said, the requirement that you MUST set an object variable to Nothing, seems to have been released/relaxed. Perhaps it never was mandatory.<<

First up let’s get rid of my name out of this; it really doesn’t matter what I said any more than what anyone else has said.

>>Perhaps it never was mandatory.<< This statement might be a bit excessive because it brings into question the meaning of the word ‘mandatory’.

If ‘mandatory’ means ‘mandatory under all conditions’ then the answer is that it is not mandatory and has not been so at least since Access Version 2.

On the other hand, if ‘mandatory’ means ‘mandatory under some conditions’ then I can’t comment about that.

Let’s be clear about the logic here because it might appear to be reversed:-
It has been proved that it is not mandatory under all conditions but it might be mandatory under some conditions.

With that logic we only have to prove that the condition of not all is correct. We are not required to prove that might some is correct.

Hence, we can disprove that it is required to Set a Recordset to Nothing. Any single instance of disproof of a general theory disproves the theory in general.

Disprove of the requirement to Set a Recordset to Nothing:-

Sub TestIt1()
    Dim lngCount As Long
    
    For lngCount = 1 To 10000
        TestIt2
    Next lngCount
    
    MsgBox "Done"

End Sub


Sub TestIt2()
    Dim dbs As DAO.Database
    Dim rst As DAO.Recordset
    
    Set dbs = CurrentDb()
    Set rst = dbs.OpenRecordset("Select * From tblMyTable")
    
End Sub

Therefore we can see that it is not ‘mandatory under all conditions’ to Close or even Set a Recordset to Nothing.

-----------

Maybe all it really is, is a requirement to talk on the internet without doing much work. I think I’ve done my bit of work so perhaps it’s time for someone else to do some as well.

Perhaps someone would like to comment on the link I posted in post #21?

Chris.

 

[jdraw]

I suggest we pause the discussion until gg returns and tells us whether or not his question has been answered.

ChrisO, I was trying to be helpful for anyone reading this particular thread. I guess to be clear I should have said-- As ChrisO has proven, and shown us with an example, setting an object variable to nothing is not mandatory under all conditions.

I agree that it matters little who says what or why; and that you never know with what authority many things have been written and quoted on the internet.

 

[gemma-the-husky]

Dave.

Because it is hearsay, I will not require anyone to believe this. I can test that code with 41 Forms and there was no memory creepage without the Set to Nothing. I can run it continuously and still get no out of memory. I can’t test it any other way but that is the result I get, no continuous increase in memory. So there is still no reproducible proof.

But that is beside the point; it has nothing to do with having to close recordsets and setting their pointers to Nothing.

Did you get a chance to read the link I posted in post #21 and did you come to some conclusion about it?

Chris.

thanks for testing the first. it was conjecture on my part, and seems not to be correct.

anyway, i thought i had posted a long reply to your other point (the link about objects as pointers?) but it seems to have disappeared, and I haven't the time to recreate it all now.

 

[ChrisO]

Dave.

I am talking about this link:-
http://access.mvps.org/access/bugs/bugs0005.htm
which is the link I posted in post #21.

Anyone have any thoughts about that link?

Chris.