[AccessD] Any limits on what can be passed as an argument?

I assume the question regards arguments to functions.

The answer is yes, but that they are passed as variants.  Variants can accept objects.  Object data 
type is just a pointer (more or less) the result of which is that the object reaches the other end 
but there is no intellisense available any more.

Having said that any thing that you can use in a dim statement, which includes dao.querydeff, 
dao.tabledef etc can be passed strongly referenced (with the datatype).  The only things which 
cannot be strongly referenced are custom classes and third party controls and the likes.

The answer to the second question is that since both query defs are stronbgly typed as a querydef 
object, when you do the set QD1 = QD what you are literally doing is setting a pointer (a memory 
reference) to a pointer (a memory reference).  Both pointers now point to the same area of memory, 
and the compiler understands that they are both a specific object type so they both point to exactly 
the same object.

In vba I do not know of any method that copies just the information in the properties and such as 
opposed to the pointer itself.  There is such a thing in .Net.

You can call any methods or set any properties of either pointer and the results are the same.  The 
object itself unloads from memory when the last pointer to the object is set to nothing. After that 
time any reference to either pointer will fail because all pointers to the object are set to nothing.

That said, even though both point to the same object, if you close the object in one, it is also 
closed in the other.  This does NOT unload the object from memory it just closes the querydef.  A 
closed querydef almost certainly will fail trying to see some (or maybe all) properties.

It sounds like either
1) You are setting both pointers to nothing and still trying to use one or the other
2) You are closing the object (via one or the other pointers) and then expecting to be able to use 
it from the other object.

I always do something like

On Error resume next
qdf.close
set qdf = nothing

If the querydef is already closed there is no failure because of the On Error resume next

You should ALWAYS be able to set a pointer to nothing, even if it is already nothing (without an 
error occurring).

In the end though you should try and track down why the code closes the object before you think it 
is closing.

John W. Colby

Reality is what refuses to go away
when you do not believe in it

On 3/11/2013 2:12 PM, Arthur Fuller wrote:
> I suppose that I could whip up a few test harnesses and discover this
> myself, but hell, why bother in a list full of experts? :)
>
> I'm wondering whether virtually *anything* can be passed as an argument.
> Can I, for example, pass a QueryDef or TableDef?
>
> I'm also wondering exactly what happens in the following (pseudo-code)
> example.
>
> <vba>
> Dim qd as QueryDef
> Dim qd1 as QueryDef
> Set qd = QueryDefs("myDef")
> Set qd1 = qd
> ... make some changes to qd, such as changing the sql property
> </vba>
>
> 1. Are changes to qd relfected in qd1? (My guess is Yes, that it's just a
> pointer).
> 2. If Yes, is there a method such as Clone which would NOT change qd1?
> 3. Can I pass qd around like any other parameter?
>
> And finally, for reasons I won't go into, I declare a qd in the
> Declarations of a form. In the FormOpen event, I retrieve the particular
> QueryDef of interest and assign it to qd. In various other form events, I
> manipulate qd. Then in the spirit of good housekeeping, I close it and set
> it to Nothing. I've tried this code in both the Close and Unload events,
> but in each place, Access tells me that there is no object qd. I'm not sure
> where it's disappearing but it is. I thought that declaring qd at the top
> would mean that it's alive until I close the form, but apparently I was
> wrong. I don't really understand what is occurring.
>
> Any ideas?
>
> Oh, before I close this, if I assign qd to qd1 as above, and then attempt
> to close qd, am I correct in assuming that this will fail, since there is a
> reference to qd (qd1)?
>
> Finally, if I can pass a QueryDef as a parameter, does this mean that I
> could pass it to a static function of the standard get/set type, and
> therefore that it would live until I specifically killed it?
>
> (Which reminds me of something I heard in a Q&A session years ago:
> Q: Do static functions continue to hold their values even if I turn the
> computer off?
> A: Well yes, but turning it back on wipes them out.
>