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

 Hi Arthur --

1. Yes
2. No
3. Yes - by Reference

Yes,  you can pass QueryDef object instances (references) to the static functions and if you assign their references to the static functions' module level variables then they (QueryDef object instances) will be kept there till you "kill" them/quit MS Access app.

A query def var should be "alive" in a Form's Close and Unload events - your code is needed to be reviewed to find why you have them destroyed.

In general: QueryDef object instance is a COM-(MS Common Object Model) object instance and VB(A) runtime is a "COM-technology client" - so all the COM-technology rules are/should be applicable to the behaviors of VBA object instances, including custom classes instances.

-- Shamil


Понедельник, 11 марта 2013, 14:12 -04:00 от Arthur Fuller <fuller.artful at gmail.com>:
>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.
>
>-- 
>Arthur
>Cell: 647.710.1314
>
>Prediction is difficult, especially of the future.
>  -- Niels Bohr
>-- 
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website:  http://www.databaseadvisors.com