Updating vba code

  • Thread starter Thread starter Daniel Thomson
  • Start date Start date
D

Daniel Thomson

I have a database that 1600 users have downloaded from the Internet and am
looking for ways to ease me sending out updates.

I'm curious if it's possible (or wise) to use vb script or VBA to update a
databases procedure code. Something like replacing all the code for Private
Sub Command1_Click() with newer code.

Any thoughts?
 
If the database has a split "front end/back end" structure, you simply
distribute a new version of the whole front-end. This does not disturb the
uer's data, which is stored in the back-end. If the front-end changes
require a change to the back-end structures, the front-end can update the
back-end structures using VBA (eg. to add new fields or tables).

HTH,
TC
 
I'm new to Access lingo.

My database is pretty simple. It's just a few tables and forms all in one
mdb file.

Am I out of luck?
 
If you've put everything into one mdb file, you now have a big problem in
how to distribute the updates. It's not really feasible to just update a
single button procedure (for example). I recomment you start learning-up on
front end/back end techniques. It is not *completely* simple, but it does
largely solve the problem of distributing updates.

But, tell me you started thinking about this, *before* you gave out 1600
copies!!

HTH,
TC
 
I think the proper answer would depend on whether your
database is used as "read-only", meaning the your users
do not actually store information in the database. They
only retrieve and display information contained within
via your forms.

If that is the case, then it would be simpler to
distribute an updated complete mdb file.
 
Daniel Thomson said:
I have a database that 1600 users have downloaded from the Internet
and am looking for ways to ease me sending out updates.

I'm curious if it's possible (or wise) to use vb script or VBA to
update a databases procedure code. Something like replacing all the
code for Private Sub Command1_Click() with newer code.

Any thoughts?
Click to expand...

It's possible, but awkward. TC's suggestion of using a split DB and
distributing new copies of the front-end is the simplest. Another
approach is to distribute a whole new database with empty tables and
one-time startup code to locate the old version and import the data from
the old version's tables into the new version. This, of course, still
requires that the user update any shortcuts he may have that point to
the old version.

Yet another approach is to distribute a "patch" database that contains
only the objects to be replaced or added, along with code to locate the
old version, create a backup copy, and then replace/add the indicated
objects.
 
1600 users and you are trying now to maintain and update a
database with naming conventions like 'Command1'? As you are
hearing, you definitely need the FE/BE setup. I can
confidently say that without even knowing what your db does.

Do your users store data? If so, you have the possibility of
wiping that out with your upgrades if you aren't in an FE
mode.

Best of Luck,

Gary Miller
 
Very good points everyone. It was originally decided that we would just
redistribute the database when a significant number of updates had been
added. Not the best approach by any means.

Can you guys recommend some study materials for learning how-to and best
practces for FE/BE database design?

Oh, that was just an example procedure name. I tried to follow recommended
naming conventions as found in documents from MS and mvps.org/access

Are there any kind Access persons around who could critique my database and
give me some pointers?

Dan
 
Very good points everyone. It was originally decided that we would just
redistribute the database when a significant number of updates had been
added. Not the best approach by any means.
Click to expand...

Bill made a good point that this would be ok if your database was *read
only*. But if the users have made any changes, you can not just give them a
new db file. That would wipe out all their changes! FE/BE is the way to go
then.

Can you guys recommend some study materials for learning how-to and best
practces for FE/BE database design?
Click to expand...

There is a database splitter wizard which will take your db & produce a
split version. I've never used it myself, but it might be worth a try.

Dirk had an interesting idea ("one-time startup code to locate the old
version and import the data from the old version's tables into the new
version"), but that is a less common approach than FE/BE, so you might want
to tread a well-worn path, first!.

HTH,
TC
 
No, not read only. Though I did build in a mechanism for users to export
their data. This exported data can then be easily imported via another
already developed mechanism. I just am not 100% satisfied with what was
developed but was under a deadline and everyone wanted to get this thing
out.

I'll investigate the FE/BE design for a future release..

Until I get that done, I'll include code in the newer releases to extract
the data added by the user and import it into the newer database.

Thanks for all the advice. This Access novice appreciates it.

Dan
 
TC said:
If the database has a split "front end/back end" structure, you simply
distribute a new version of the whole front-end.
Click to expand...

My FE is large, and update usually is to the code only. Therefore
my code exports standard module, and destination db 'A" imports it.
"A" exists only for purpose of applying module to ultimate target db "B".

I cannot find syntax to refer, in A's code, to **module** in B.
 
Just answered your other post.

TC


. .net> said:
My FE is large, and update usually is to the code only. Therefore
my code exports standard module, and destination db 'A" imports it.
"A" exists only for purpose of applying module to ultimate target db "B".

I cannot find syntax to refer, in A's code, to **module** in B.
Click to expand...
 
Back
Top