How do I programmatically import a class module?

[bkdraper via AccessMonster.com]

background:
I have an Access app (ACC2000) that is constantly undergoing code changes as
business requirements change. The front-end is starting to get so big that
it's taking forever for my clients to download new copies of the front-end
when ever I make a code change and need to redistribute because their network
connection is painfully slow. So I thought that maybe I could start chunking
some of my larger blocks of code into external libraries referenced in the
front-end, that way I can make a change to a library, recompile and that'd be
change complete. Until I discovered that every time I recompile a library the
front-end stops working until I un-reference and then re-reference the
library I changed (that must be a part of whats been lovingly referred to as
dll-hell over the years.)
So then I thought maybe I can just leave my code chunks as class .cls files
on the network share and then use flags in the db to tell the front-end when
it's time to download and import a new class module (kinda like patching, i
suppose).

question:
thats a cute theory i have there but I have no idea how to or if it's even
possible for my front-end to programmatically remove and then import a class
module into itself. Anybody got any tips for me on how that might work?

Thanks.

 

[Albert D. Kallal]

You can import code, but then again, I NEVER recommend Distributing a mdb,
as a mde is smaller, loads faster, and un-handled errors don't blow out
global variables. this means you resulting application will never lose the
values of variables due to errors, and that makes Your application a lot
more reliable.

And, more important, users can't modify the forms and even view your code if
you use a mde.

I have a medium application that has 160 forms, 30,000+ lines of code,
about 100 reports, and tons of stuff. As a mde, it is about 6.8 megs in
size. As a zipped mde, it fits on ONE floppy. It takes very little time to
download even on a mediums speed internet connection. (well under a
minute...it only about 1.5 megs in size).

So, you must have one whopper of a large application . You can import code,
but really it makes no sense when the WHOLE application zipped up is only
going to be 1 or 2 megs in size. furthermore , importing code means the
application has become un-compiled ..and that is risky , will mean you need
to re-compile the code.

Until I discovered that every time I recompile a library the
front-end stops working until I un-reference and then re-reference the
library I changed (that must be a part of whats been lovingly referred to
as
dll-hell over the years.)

While I really do support your goal of having a "library" that you use, if
you want reliably Distribution , put all the code in the ONE front
end....and
simply give them a whole new fresh copy.

have no idea how to or if it's even
possible for my front-end to programmatically remove and then import a
class
module into itself. Anybody got any tips for me on how that might work?

the transfer database command supports all objects. The problem is you
really don't have to tools to keep track of what you changed. Yu might
change 3 standard modules + one form's module. If you miss part of the
update, then you going to have a front end that is likely broken and does
not function correctly. that your users complaining, and you don't know what
part didn't import correctly or what pieces of code were broken with the
update, and now when you try and update again are you go over right the
oldest encoded or what just happened? is just simply too difficult to update
pieces and bits that the same time, because of one's update fails, you have
no idea what the end user now has.

in addition to the transfer data base command (check it out my help it does
allow transfer of modules between PT bases), you can also use the
un-documented saveastext, and
loadfromtext (try them the debug window, you see the inteli-sense help).
This feature allows you export a form, report, modules etc as text files,
and then import them (ideal for your idea here).

While what you ask is possible, I think is is way too much trouble and has
too many downsides for the efforts. I would simply distriubte a SINGLE
compact mde to your users. I use the free open source in a wince taller
which also compresses it to it leaves the same compression leveled as a
zipped file, and therefore you reduce the size of your distribution by quite
a bit. and the anno installer also allows you to set up for cuts and things
on your desktop. the end result is that for my users to update their
applications in an access of applications goods to the following set of
screen shots and it's quite simple:

http://www.kallal.ca/ridestutorialp/upgrade.html

By keeping everything in one single coherent mde, you not only simplify your
distribution, and updates, but you also make it considerably more reliable
from breakage and it not working.

I wish we had an easy way of distributing the library update code without
modifying the application. My experience over time simply have led me down
the road of keeping it simple, and keeping it as a single simple update...

 

[bkdraper via AccessMonster.com]

Thank you very much for a very detailed reply.
All your info has proved most useful with both your recommendations on going
MDE (I never knew that MDE's kept globals from losing state after an error),
and your info on how to accomplish my import idea.
I think I'll pursue the MDE idea because I too like keeping things simple and
all together in a single file and if a zipped MDE is really that much smaller
then that'll be perfect. Currently my MDB is 8.9mb.

Thanks again, i appreciated it.

 

[Tony Toews [MVP]]

I think I'll pursue the MDE idea because I too like keeping things simple and
all together in a single file and if a zipped MDE is really that much smaller
then that'll be perfect. Currently my MDB is 8.9mb.

Typically an MDB/MDE zips down about 3X or 4X.

However what kind of network is it that downloading an 8.9 mb FE is
very slow?

Also when was the last time you did a decompile? If that hasn't been
run for months of development then that could save significant amounts
of disk space.

Decompile or how to reduce Microsoft Access MDB/MDE size and decrease
start-up times
http://www.granite.ab.ca/access/decompile.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[bkdraper via AccessMonster.com]

thanks for the link, I've not heard of decompiling my MDB before. I thought
decompiling was something reserved for reverse-engineering an executable
(probably two very different things.), so that article you linked to looks
like it'll make for some very interesting reading.

By slow network connection, I mean pathetic network connection. Excrutiating.
Embarrassing.
I don't know if this office has a misconfigured router or switch or if their
gateway into the data center is out-dated (this is a satelite office of a
larger corp.). I can only speculate since I dont have permissions to touch
that stuff, but everytime I go to SpeedTest.net from one of the office
machines (i go every now and then hoping to be surprised that the numbers are
better. They never are.) I always average 150-300k on the down and 1.5mb on
the up (i know, that should be the other way around, but it's not.) So I
figure that has got to be some misconfigured hardware somewhere, but it's
outside my charter for the company so I don't get to fix it, I only get to
work with it.
To give you an idea of what I mean by slow, the app I speak of in this thread,
plus a couple others that I've developed for the office (front-end on client,
back-end on network share) take 5 minutes or more for a user to open, and I
don't think these apps start ups are all that complex either. query a link
table to see if an update flag is true, then open a bound form (straight
table connection, no complex query) and a couple bound drop-downs. pretty
simple.
And then this 8.9mb MDB averages 5 minutes to download when the users have to
update.
Thats my definition of slow.

Anywho, thanks again Albert and Tony for some excellent advice and links.
MDE is good enough for me and decompile to keep my app tight for a while.
(thats why I write code, because my poetry sucks.)

 

[bkdraper via AccessMonster.com]

Holy file-shrinking batman!
That's really impressive!
decompiling shaved 33% off the MDB, taking it from 8.9 down to 5.7. And then
making it an MDE shaved another 1mb off of that for a grand total of 4.7mb
file size. And then it zips down to 650k.

that is going to make life a ton easier for my people. Thanks a million guys
for all your advice.

 

[Marshall Barton]

Holy file-shrinking batman!
That's really impressive!
decompiling shaved 33% off the MDB, taking it from 8.9 down to 5.7. And then
making it an MDE shaved another 1mb off of that for a grand total of 4.7mb
file size. And then it zips down to 650k.

You forgot to mention using Compact after the Decompile and
that YMMV ;-)

 

[David W. Fenton]

To give you an idea of what I mean by slow, the app I speak of in
this thread, plus a couple others that I've developed for the
office (front-end on client, back-end on network share) take 5
minutes or more for a user to open, and I don't think these apps
start ups are all that complex either. query a link table to see
if an update flag is true, then open a bound form (straight table
connection, no complex query) and a couple bound drop-downs.
pretty simple.
And then this 8.9mb MDB averages 5 minutes to download when the
users have to update.
Thats my definition of slow.

I think this network is not adequate for running an Access app
across it. I would refuse to support such a configuration if a
client proposed it to me.

 

[Tony Toews [MVP]]

Holy file-shrinking batman!
That's really impressive!
decompiling shaved 33% off the MDB, taking it from 8.9 down to 5.7. And then
making it an MDE shaved another 1mb off of that for a grand total of 4.7mb
file size. And then it zips down to 650k.

Startup time is probably down a lot too.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[bkdraper via AccessMonster.com]

Marshall, very true. The benefits were realized after decompiling and then
compacting. The compacting afterwards was definitely an important step. And
I'm sure that the only reason the difference was so extreme this time was
because this app is near 4 years old now and this is the first time I've done
a de- and re- compile. Next time I do it, the change will certainly not be
as drastic.

Tony, your right. The start up is noticibly faster now.

David, yes, in something of a utopia-state I'd just flush this headache like
a bad burrito, but in my poor little reality I've commited to these people
and over the years I've developed relationships with them so morally it'd be
impossible for me to walk away, so here I stay finding ever more creative
ways of making it work.

On the upside, since necessity is the mother of all invention, the work I've
done for this client has made it necessary for me to make code optimization
and minimalization a way of life which has served me well for other clients.
And techniques i've picked up here and there for keeping recordsets in memory
to minimize network traffic so that app's at this site would operate at a
half-decent speed I've applied to app's at other sites that have "normal"
network connections that have made those app's run lightning fast. So all in
all, I suppose work for this client has been a blessing in disquise, silver
lining, all that type stuff.

 

[David W. Fenton]

David, yes, in something of a utopia-state I'd just flush this
headache like a bad burrito, but in my poor little reality I've
commited to these people and over the years I've developed
relationships with them so morally it'd be impossible for me to
walk away, so here I stay finding ever more creative ways of
making it work.

The right thing to do is to go the client with your hair on fire and
tell them they need to fix the damned network so it works correctly,
and if they don't do that you can't be responsible for the results.
And will charge $250/hour to clean up after the mess caused by their
badly managed, substandard network.

Give them time to fix it.

If they don't, walk away.

But if you never tell them they have a major problem that needs to
be fixed, but instead just patch over it, they will constantly be
having problems, as there really is no getting around the problems
that are caused for an Access application by inadequate networks.

This is one of those "teach them to fish" situations -- you're
fishing for them, enabling them to keep doing it wrong. If you are
truly concerned about them, instead you'd "teach them to fish" and
help them rectify the underlying problems, instead of just papering
over it every time it comes up.

 

[Tony Toews [MVP]]

I don't know if this office has a misconfigured router or switch or if their
gateway into the data center is out-dated (this is a satelite office of a
larger corp.).

Ah, a satellite office. Then they are likely running the link at T1
speeds or 10 mpbs something like that. Access does not do well in a
WAN scenario. Performance will suck and your client will be vulnerable
to corruptions.

The options are to move the client to using Terminal Server or change
the backend to using SQL Server.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/