Access 97 mde database to Access 2000 1

[ruthcali]

I created a mde database using Access 97. (it's NOT a front end/back end database).

Now our department is migrating to Access 2000, but it will take about 1 month for all the users to complete the upgrade.

From what i have read in these threads and on help screens, can someone verify if this is what i do:

Make sure noone is in the 97 mde database. Go to the user's computer who just got Acc2000. Open the original mdb 97 database. Choose 'Open' (not convert). once the 97 mdb opens, make sure i can compile, add any reference necessary, then create the mde file.

But will my 97 users still be able to open the newly created 2000 mde file?

How can both sets of users use the mde database?

Thanks,
Ruth

 

[930driver]

An mde has been stripped of it's code in it's text form. Without this text you cannot edit the design of forms, reports, and modules. This also means that you cannot convert a MDE file to any other version of Access. You must convert the mdb to A2K and then recreate the mde. Your A97 users will not be able to read the A2K mde.

If you must have both sets of users able to run an mde you have to maintain to different versions. "The Key, The Whole Key, and Nothing But The Key, So Help Me Codd!"

 

[jbehrne]

Hi,

To answer your first question - No, Access 97 users will not be able to use the 2000 db. However, I think that the Access 2000 users should be able to use the 97 version without converting it (but not entirely sure - but I am running various dbs that are in Access 2000 through Access 2002 and Access 2000 without any problems). You might be able to get the users to use a single copy of the database by splitting the tables from the queries, forms, reports, etc. Basically, you will have a backend containing tables and 2 versions of the frontend (containing the queries, forms, reports, etc.) - one for 97 users and one for 2000 users. Hope this helps,

jbehrne

-Anyone who has more exprience with this please feel free to post!

 

[ruthcali]

930 driver and jbehrne,
thanks for writing!

i guess i could change my 97 mde database back into the original 97 mdb database for the month. I'll just tell the users to change their shortcuts for the month.

Then both sets of users can use the database, right? and i'll just tell the 2000 users to choose 'open' and not 'convert.'

If a 97 user is in the mdb database, can a 2000 user open the database for the first time?

Will the 2000 user get the Open, Convert dialog box each time they open the database or only the first time?

Thanks!

 

[jbehrne]

Hmmm... both users should be able to open the database. I think once the 2000 user has selected not to convert the db it shouldn't ask them to convert again (I know that once a 2002 user opens a 2000 db and doesn't convert it they don't get the message again, and hopefully 2000 & 97 follow that model - but it wouldn't hurt to check it out!) I honestly don't know if a 2000 user can open the db for the first time while a 97 user is currently using it. If you are worried why not just get them to open the db while 97 users are logged off (like at the end of the day - unless you are working in a business that runs 24/7...)? However, I did run across a few articles that you might be interested in checking out:

http://support.microsoft.com/default.aspx?scid=kb;en-us;310804

http://support.microsoft.com/default.aspx?scid=kb;en-us;241141

http://support.microsoft.com/default.aspx?scid=kb;en-us;246033

http://support.microsoft.com/default.aspx?scid=kb;en-us;216163

http://support.microsoft.com/default.aspx?scid=kb;en-us;325157

Hope these help,
jbehrne

 

[930driver]

Beware:

Since you don't have it split back/front end it's almost inevitable that one of your A2K users will inadvertantly convert it, affecting all users. Make SURE you have frequent back ups if you are going to go this route.

Better would be to split it and give each user their own copy of the front end. "The Key, The Whole Key, and Nothing But The Key, So Help Me Codd!"

 

[ruthcali]

930 driver and jbehrne,

thanks for writing again! sorry for the delay in writing back, but the IT guy took away my computer to load Win and Office 2000. So either today or monday i'll get it back. (i'm using a loaner computer now).

When he saw that we use Access, he said he knew how to load both versions on one computer. It's also explained in jbehrne's 2nd link above. Thanks for the links, i read each one and they were very helpful.

930driver-the reason i never split my database was because i'm frequently making changes to the forms or the code in the forms. (can you add a button that...can you change this name to...). To do this I make the changes in my original mdb and then import all the tables from the mde and then make a new mde and post that mde back on the network drive.

If I split the database and the users all had a front end on their hard drives, i would constantly have to be emailing them the new version whenever i make a formatting change.

 

[930driver]

Even if you leave the front end on the server you are still safer if you split it. That way you can make front end design changes without fear of wrecking your data. In fact you could test your new front end against the back end data and still leave the current version in play for your users. "The Key, The Whole Key, and Nothing But The Key, So Help Me Codd!"

 

[ruthcali]

930driver,

that's a good idea to split the database and leave both the front and back ends on the server. but is there really a benefit in doing that? i know when you put the front end on the user's hard drive, it makes the database faster. But, will leaving the front end on the server give any speed benefits or other benefits?

I just got my computer back today and so far it seems like everything is working. i have both Access 97 and 2000.

 

[jbehrne]

Hi,

I usually just leave the frontend & backend (in different folders) on the server and create shortcuts to the frontend. This way if I do make changes to the frontend (I.E. - create a new form, etc.) I don't have to redistribute the frontend to everybody... As far as network traffic goes, I work for a company that uses a fiber optic intranet to link our offices - so speed isn't a concern. However, make sure that you don't have to many concurrent users (I find that at any given time there are about 5/7 users on anyone db at a time). Anyway, I hope that this helps you out in some way,

jbehrne

 

[MichaelRed]

(it's NOT a front end/back end database).


see thread181-30072


I do not recall that the total discussion of the arrangement is in this thred, but the code to do the auto update is here.

The arrangement which is the target of the discussion (for MY multiuser maintenance) is:


Each User has the FE installed locally.

There is a MASTER (FE) which is where ALL approved / finalized updates are placed.

I maintain a Working copy (of the FE) on the 'db-admin' machine (or server), which is NOT the Master.

Each proposed change is reviewed and approved by the User group. This group 'meets', discusses and votes on each item, usually in the forum of e-mail. I (db-admin) implement all approved changes in the Working copy and do some testing. When I think it is correct, it is presented to a seleted group for further testing/commentary/re-pair.
When 'testing' is complete, the changes are implemented to the Master copy. The routines (see referenced thread) automatically 'update' the users FE copies the next time they start the program.

There are some other 'issues' which should be addressed in the use of multiuser dbs. I will not attempt to 'resolve' them here, but just list some topics. I and others have commented on most of these extensively in these fora, and some soloutions are presented for those who care to use hte search capabilities and winnow the wheat/chaff stuff.

First, the referenced thread will not work with the MDE format, so if there is an administrative reason for the use of that (.MDE) format at least the update process cannot be done (at least not in a piece-meal sense). You could use a different process to detect a NEW .MDE and copy it wholesale to the user systems.

A:[tab]I maintain a form / table in the db for users to report issues problems to me through the app itself.

B:[tab]ALL useful dbs should (MUST?) implement security. Without the security protocalls, many users could easily generate the trivial procedures to destroy the database. Som (actually MANY) of the ways this could be done are close enough to legitimate work that ic could be done mistakenly. Placing the db into the .MDE format will not prevent some / many of these.

C:[tab]If a db is at all useful, it must be backed up. As 'they' say "sttuuuffff" happens. And -at some point it WILL! Many network backup schemes rely on Win (O.S.) for the actual file copy. Win WILL not copy a file while it is in USE. So, you need to be quite sure that the 'net cops' are actually accomplishing the back-up. Ask them -in 'writting'- several questions
[tab][tab]1. Do they review the back up log on a daily basis
[tab][tab]2. do they notify each "owner" of EVERY occurance of a filure to back up hte files htey (the owners) are responsible for?
[tab][tab]3. Can (and WILL) they 'disconnect' all users (of the files YOU are responsible for) before doing a backup?
[tab][tab]4. Can YOU review the backup log re YOUR files at least occassionally?

If you are not completly satisified with ALL of the above - go directly (and in writting) to your supervisor. Do not "STOP" an informing the super of your concerns, but go straight to the point that he takes decisive action to resolve these concerns.

D:[tab]Multiuser databases often need to review the sequence of events in a process. This is ONLY possible if the individual system clocke are synchronized or every 'transaction' uses the server clock. I (at least so far) have found no pratical soloution involving the latter, however syncing the individual systems is a routine network process, so -AGAIN- address this along the lines of the backup. Formal correspondence to the 'net cop' of choice through formal completion / acknowledgement.

E:[tab]In realistically maintainong a multiuser db, some issues of 'who-shot-john' (and WHEN did the shooting occur) will arise. The 'reality' game of CLUE. To provide the evidence, you MUST have a transaction log, and it MUST be complete and accurate (back to ye olde time stamps'!). (I have written faq181-291 which can be used for BOUND forms in Ms. A. whichcovers this.)

Most 'transaction logs' quickly grow to be larger than the databases. You will need to have a process which 'archives' the transaction log records to an inactive storage on a regular (and perhaps frequent) basis. Ideally, transaction logs should be on DIFFERENT servers. Transaction logs not are useable as a method of 'reconstructing' the data up to the point of a 'crash' - but they will not be useful if you wait for the crash to occur before writting (and testing) the procedures which do the re-construction. Again, from MY perspective, this should be an important issue and receive priority attention (and 'funding') from the supervisor - with appropiate (and FORMAL) documentation.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[ruthcali]

Wow Michael.

Thanks for your help and your comments! And the code on your referenced thread is very impressive!!

I wish i could understand it all, but that takes time. I'll play with it this weekend.

Thanks again for helping!!!