Track Users

[The_Doc_Man]

OK, two issues

1. Build a split database with Front End, Back End (FE/BE). Put the FE and BE in the same shared drive. Tell your users via e-mail or some other way when you update the FE. Let them copy the FE to their local machines.

2. Tracking users is BEST done by having a startup form that says, in effect, "Howdy, pardner!" and then appears to go away. BUT... in the startup form's OnLoad routine, you can update a hidden table in any way that you want.

What I do is use the Environment("Username") because that tells me who Windows thinks is logged in. You said things about "roaming profiles" that makes me think this would work for you, 'cause roaming profiles implies a domain-based login system.

Now, to REALLY get fancy, your startup can look at some arbitrary table in the database that shows the version number of the FE. Then have the startup form compare some constant in its own code to the FE version and tell folks, "You are running an out-of-date version of the FE, download the new one."

What I also did was rather than have the starup from exit, I made it minimize itself. Then when the user closed the DB, the form's OnClose routine gave me logout info.

Once you have that form hidden in the background, all sorts of useful things can happen. Like if you have a table of scheduled events, put an entry in it for a date and time of day. Run a timer in the form. It runs even in hidden forms. When an event comes due, have the form pop up a warning that you need to take the DB down for something like backup or maintenance. And if they don't log out by a certain time, the form can do it for you with a DoCmd.Quit in the form's timer code.

 

[jj72uk]

wanting to try what you all suggested by I have a user using it at the moment...

maybe i should design a way to kick them out

 

[SOS]

wanting to try what you all suggested by I have a user using it at the moment...

maybe i should design a way to kick them out

One of the good things about doing separate frontends - you can work while they work. The only time you need someone out of the backend is if you need to work on a table that is being used. And, if you design it right up front, the likelihood of that is very low.

 

[jj72uk]

The FE BE looks great but I just don't think the users will buy it. They are sales team leaders, not technically minded and it was a effort in the first place to get them to go to a central place. To give them each a seperate FE will mean that either they wont use it... or.... they will complicate things and therefore come to me for tech support.

The DB are on a rolling monthly basis, meaning that at the month end it gets archived and they get a 'clean' one, meaning if I were to do a FE BE they'd need a new FE each month, again making it to complex for them.

I only got 1 corruption with last months DB and this month has had one as well.

I keep a back up blank DB so if it corrupts all I need to do is import the tables. The repair job isnt hard or time consuming. Just an annoyance really.

Also the users dont have any drive space on there local machines. This has been locked by admin and even if they could with there roaming profiles on the network domain having a FE on the local machine wont help!!

 

[SOS]

Well, you've got to do what you've got to do. We've pointed out the benefits and drawbacks to both ways and it is now up to you to go with what you either need or want. Sometimes you get stuck and there is no "easy" answer based on other constraints that make doing the right thing impossible.

So, anyway - you've got the information and if it proves to be too painful in the way you are sounding like you will need to go, you can revisit it with your manager and the IT group later. So, don't fret too much. We've given you what we know based on years of experience and sometimes that just isn't enough to overcome internal constraints that are thrust upon you.

So, good luck with it and we'll certainly continue to try to help as much as possible.

 

[gemma-the-husky]

the thing is, a database is more akin to your accounting system - this will undoubtedly have a single set of data tables, and each user will run code in his own environment, although the exact way this is done depends on the system.

in the case of access the safest way to achieve this is by having a split fe/be. if you ever have a system that stores data in local tables - say temporary order entry files - then you have no choice, otherwise you may find one user could erase another users temporary tables - maybe something like this is causing your problems.

 

[jj72uk]

I dont think the users are clever enough to be messing with the tables.

The whole use of the DB is using various forms that have buttons, drop down lists and input bullet points etc etc.

There is no direct input into tables or running quieres as its all done from a form end view

 

[jibbajabba]

At the very minimum, split out the tables and keep the existing database name and location for the front end - Users don't experience any changes - You name your backend "currentdata" and just literally replace the backend file on the server once a month with an empty version - You wouldn't need to make any monthly changes to your front end at all. This will decrease corruptions

 

[jj72uk]

Ok.. can the FE handle multiple users using it at one time?