Multi user environments - do variables remain constant per user?

[scott0_1]

End of day Friday and this occurs to me with a project I'm working on...



I have one shared database and users cannot have their own front end due to IT policy.

When the database opens, it creates a new record. It saves the primary key for that record in a global variable on the main form that stays open the entire time. The variable is gintID on frmMain. The user works through many forms, none of which are bound. They all use DAO recordsets to manipulate data. At the end of the process, when the user is done and they close the main form, the record is deleted.

I have not tried this with multiple users using the database at the same time, but a potential problem popped into my head, and I'm not sure what the answer is.

If I'm the user and gintID=10 when I log in, will that remain constant during my use? Or if Timmy in the cubicle opens the database and creates a new record that creates gintID=11, will that become my new gintID?

I'm heading home for the weekend, but I will lose sleep over this. I don't know why!

If you can answer my question, that would be great... Or if you can recommend an even better solution, I'd take that!

Thanks for your help,

Scott

[Micron]

I know that when sharing fe, any records, temporary or not are exposed to all users, so I don't see why a public variable would not be. Obviously you don't want to hear about how this db is going to corrupt at some point because it's not split, so the banality of this is that whatever "fix" you employ, it won't last. At some point the db WILL corrupt and no telling when or what will be affected.

IMHO, you need to push back. Read up on split vs not split dbs and grab all the info you can find and present it to your boss, who then needs to rag on the IT gods (or their boss) and make it happen. The alternative is to pay you to develop and maintain something that is doomed to fail at some point. You might want to keep the email where you present your findings so that you can refer back to it if they say you did a crappy job.

[pbaldy]

I agree with pushing back; this is ignorance on their part. The front end will corrupt sooner or later, and may take the back end with it. If they don't want files on each computer, put separate front ends for each user in folders on the server or something like that.

[Missinglinq]

Running a multi-user database without each user having a copy of the front end on their machine is, indeed, a tried and true method of creating all kinds of problems, including timing problems, record-locking problems and major, major data corruption!

The fact that some users report having had multi-user, non-split DBs running successfully for some time is totally meaningless! I've seen reports of such apps running smoothly for as long as 14 years and then bombing out! And once trouble starts it never stops! All it apparently takes is some combination of events to occur and BOOM!

It's not a question of will the app become corrupt, but rather of when will it become corrupt. And once this type of corruption starts it will occur over and over and over again, until the app is split!

Linq ;0)>

[orange]

I agree with the other responders. You are headed for corruption when you have multi-users sharing a front end with MS Access.
It is time for IT Policy to understand that the standard operating procedure for multi-user MS Access is a split database with common back-end and each user to have his/her own copy of the front-end on their own PC or equivalent (Citrix etc).

There are several posts on this subject in forums. Here is a link to an article on MS Access Splitting and multi-user by FMS.

Good luck

[CJ_London]

from how you describe the process, even if each user does have their own front end (and I'm with everyone else on the requirement), I can see potential issues based on how you are creating GINT - user a opens the db, GINT 10 is created and read - how is it read? dlookup or similar? then when the user closes the db, GINT 10 is deleted as an individual records? or (since the implication is this is a 1 record table) all records are deleted? What happens if there is a power cut so the user cannot delete the record - is there a process to delete it when next opened?

I also note you say shared db - no indication the db is split other than saying 'users cannot have their own front end' - which again is a must.

[June7]

Do users have their own install of Word and Excel and other end-user apps? IT needs to understand that Access frontend (or VB.net or whatever is used for frontend GUI to backend data) is an end-user app and should be installed on each user workstation for best performance. Running copy from a folder on server should work but performance could be impacted.

Suggest you conduct a test and find out what happens to gintID with simultaneous users.

I agree splitting db is best when there are multiple simultaneous users. I did develop one non-split db with multiple simultaneous users (user decision contrary to my admonitions) which has worked but there is absolutely no code, not even macros. Very simple very small db.

[scott0_1]

Thanks for the advice everyone. Split the DB! Now it's a matter of distributing the front-end to everyone and keep it up-to-date. Harder than it sounds, believe it or not!!!!

I marked the thread solved, but I'm still not 100% sure of the original question... I'm about 99% sure that on a shared front-end, the variable will change for everyone already using it. Splitting and distributing the front-end will solve it though!

[pbaldy]

TNow it's a matter of distributing the front-end to everyone and keep it up-to-date. Harder than it sounds, believe it or not!!!!

Might be easier than you think. Most of us use some sort of automated updater. Can be a batch file, VBS script, etc. Basically the user runs the updater, not your app. The updater copies the app from a network location and then starts it. More sophisticated versions only copy the front end if it's changed, create folders, etc. Not on my computer right now so can't find an example, but search on "front end updater" and you'll probably find some ideas.