[AccessD] References (again) - Access 97

Hi Robert

That increase is not a minor one.
I have advice on this. Perhaps others can chime in?

/gustav

>  Except some times, and I'm not sure of the what or why's, the file
> increases quite a bit. One of my FE's weighs in at about 22 Megs when all
> nice a de-compile and re-compiled and compacted. As soon as the db has to
> deal with a reference change and re-compile it's self, it bloats to around
> 47 megs. The ONLY way that I have found to get the size back down to a
> reasonable 25 megs is to use the **Internal** compact and repair. Performing
> the compact and repair externally does very little (maybe 3-4 megs) to
> reduce the size..

>  It's has been a problem from day one.

> Robert Gracie
> www.servicexp.com


> Good!
> I wouldn't worry about the small increase in file size.

> /gustav


>> Gustav and Charlotte:

>> Thanks.  I was reading Charlotte's post yesterday and, thinking, well,
>> yea, DUH on me...when it occurred to me that I'd seen all of this before
>> or something similar...so I went to the archives and started searching on
>> 'references' and found where you (Gustav) had written a note to search on
>> what you just now told me to search on (again...ha!).

>> I found exactly what I needed and it works!  See.  Old programmer memory
>> doesn't really die or get erased, it just bytes the dust occasionally...

>> I did notice that every time it recompiles the code (automatically thru
>> the autoexec), the app file size grows some.  And I can't tell it to
>> compact it afterwards because then it would fire the autoexec again and go
>> on forever.  Is this an issue or should I just live with it?  The file
>> size itself is not an issue, but it seems kind of ... umm ... messy to me
>> to keep growing like that.

>> Thanks again for all your help...

>> Greg Smith
>> gregsmith at starband.net


>>> Hi Greg
>>>
>>> Charlotte is right. If you feel you have a need to fiddle with the
>>> references, this is the very first thing to do. No exceptions.
>>>
>>> Also, doing so will leave your app decompiled and you may need to
>>> recompile afterwards.
>>>
>>> We had a long thread on this topic.
>>> Look up the archive on
>>>
>>>   "Broken References in Runtime AXP and A97"
>>>
>>> of 2003-07-23.
>>>
>>> /gustav
>>>
>>>
>>>> Greg,
>>>
>>>> It is logical that you cannot declare any objects before you verify
>>>> the references.  Even if the Office library isn't the one that's
>>>> broken, you need to test the references before you do *anything* else,
>>>> including declare object variables as anything but Object.
>>>
>>>> Charlotte Foust
>>>
>>>
>>>> -----Original Message-----
>>>> From: Greg Smith [mailto:GregSmith at starband.net]
>>>> Sent: Thursday, August 05, 2004 6:58 AM
>>>> To: accessd at databaseadvisors.com
>>>> Subject: [AccessD] References (again) - Access 97
>>>
>>>
>>>> Hi everyone...
>>>
>>>> Thanks to everyone who responded to my earlier post(s) about
>>>> references and how to find broken ones (I don't have my list here at
>>>> work so I don't have all the responses).
>>>
>>>> I still have the references issue.  And it may be because of how I'm
>>>> starting the program or how I have the references set.  There is only
>>>> one right now that is giving me the PITA, and it's to mso97.dll in the
>>>> Office directory.  Hard to test that one too, because if you delete
>>>> it, Access won't start.
>>>
>>>> I can use the References.AddFromFile(...) code to set the reference.
>>>> But there's a catch-22...if I don't have a reference to the MS Office
>>>> 8.0 Object library, then the code:
>>>
>>>> Dim cbr as CommandBar
>>>
>>>> fails just before I can set the reference using:
>>>
>>>> SetRef = References.AddFromFile("c:\program
>>>> files\msoffice97\office\mso97.dll")