[AccessD] References (again) - Access 97

 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


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Friday, August 06, 2004 10:35 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] References (again) - Access 97


Hi Greg

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")

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com