FE version check

[ducker]

After my last thread I'm looking to split up all my databases in to a full FE and BE configuration. Someone suggested a way to automate a client upgrade, where I do a version check when the user starts the FE.

Has anyone implemented something like this yet?

I'm trying to think of a way that I could upgrade the FE. If a user starts the FE, and then I have code run on startup to cross check a record (that contains the version), now if I have to replace that same FE that the user currently has open. How can I overwrite that FE if the user has it still open.

I'm using AC97 in Windows 98.

Any suggestions welcomed!

-Mike

 

[Pauldohert]

I use something which - reads a record from the FE and BE and compares them - if the match is not correct the user is infromed and they may not log on. They are informed to run an update.

There is an update program also installed - which simply copies the code from the server to the PC.

Works ok - takes a few seconds for the user to update an OLD code version to the new one and get running again.

 

[ducker]

hm... like simply throwing up a pop up box that says,

"You must update your client. Please exit and run G:\updates\UpdateFE.bat"

Hm that would work.

Another FE/BE situation I have is where I have 4 users. 3 of them frequently do their own queries/reports/etc. How can I still have multiple FE clients and keep them in sync? I'm sure they create queries that will be needed in the future, so I can't simply overwrite their personal FE client whenever there is a major change to the 'admin' FE client.

-Mike

 

[Pauldohert]

I've never let users update anything - if they want to do their own reports and queries - they must do it in another mdb, so the update doesn't affect anything that they have done.

Be interested to see how others do it!

 

[Pat Hartman]

That is my policy also. Letting users update your db is a recipe for disaster. Let them make (or make for them) a separate db that is linked to the be. They can do whatever they want. If you have security issues, the be will need to be secured so that they don't have update access to it.

 

[ducker]

and if the users and to shair the custom queries, reports, etc?

tell them too bad!! or simply have them export/import between their private versions?

-Mike

 

[daveUK]

ducker - sorry to hijack your thread

pauldohert - Could you upload the database or some of the code as I'm going to be implemeting a system within the next couple of weeks and I'm looking to include something similar in my system.

 

[Pat Hartman]

and if the users and to shair the custom queries, reports, etc?

- You never tell a user "too bad". At least not if you want to keep your job. You find a workable solution that doesn't jeopardize the rest of the project. Allowing users to make modifications to database objects when the db may be opened by other users for data entry is irresponsible once you understand the potential for damage. I for one am very happy that Microsoft changed its position on this problem with the introduction of A2K. I see that you are still using A97. Sooner or later, you're going to have to convert to a newer version and you will find that Jet simply no longer permits multiple users to change objects.

If they want to share things, give them a shared db on the server to use. However, unless you also install SourceSafe on their PCs, Jet will still not allow them to all be in the db creating/modifying objects at the same time. Go to the MS kb and look up "silent changes discarded" if you want to be really scared. So, they may just decide that having their own db to work with suits them just fine.

 

[Pauldohert]

http://www.access-programmers.co.uk/forums/showthread.php?t=66195

The update works very simply by copying a file from the server (the master mde) onto the users PC and overwriting their old version of code. - all I need to do is update a record in the BE tables to say Version 10, and put the new code also flagged to be version 10 on the server.

When the user logs on with a version 9 code - it throws them out and tells them to run the update program ( which was installed with the main application)

I think I have used something similar to what is found in the example above to copy the file across, but I am sure there are other ways to do it.

My update program is an mde - it lists all file paths in tables so that differant PCs can download the code to differant folders etc and the master code folder too can easily move. Also it covers numerous differant applications updates.

Paul

 

[ducker]

- You never tell a user "too bad".

Oh I know that. I ment it in a tongue-n-cheak sort of way. My mantra when someone asks if it can be done is : " Sure, anything CAN be done pretty much in Access, how long do you want to wait for it to be implementated though?"

Thanks for all the feedback on this situation! I'll start attacking one of my databases and see how it goes!

-Mike

 

[ducker]

Given this type of setup, how would I update/add additional fields to the tables in the BE?

I'm thinking I'm going to have to toss everyone out of the system in order to make this modification.

-Mike

 

[GabrielR]

Keep Databases In Sync

Hi Guys,

This is the method that I use:

Roger's Library Example

In short:

Database has to be splited FE/BE

FE on Client's Machine, BE on File server - Nothing new Here.

Master copy of a FE on the File server Also. ( This will be the current version of the FE)

System Objects table of FE on clients Machine is linked to System Objects Table on FE in file server

Whenever there is a difference between those two tables, (A date or a new object in the Master Copy) the presence of records in a specially designed query will trigger the apearance of an otherwise hidden objects: A label with a fancy statement like: " There is an update ready to install, please click on the update button"; and a Button.

Once the button is clicked it will trigger an simple batch file that will copy the Master file to the clients hard drive: You got a very powerful Update feature there.

Now some comments on my experience with this:

I use it in all my DBs... I program for the 4th largest Education district on the US, so imagine how may users and the different conditions. It has never failed.

Users Love it, and, for my the best advantage, it provides a mean to do fast deployment, that is you make an early release of the DB, to let people work, and upgrade or add features on the go, without disturbing users.

Final Point: I have in my local Drive, a copy of the Same DB, this one not conected to Master in the file drive, I make all changes here, test it and simply export the modified/new objects to the Master, that triggers the users to have the message and the button in the switchboard for them to update.

Kudos to The authors of this utility

Gabriel R

 

[daveUK]

Thanks for the links, I'll check them out.