Kick a user off the backend dbase

[fishhead]

Is there a way to kick a user off a backend dbase when the backend identifies and outdated Frontend version?

I have some users that keep using an old outdated frontend application that appears to work for them but cause problems they don't see. I'd like a way for the backend to shut them down if the version they are using isn't current. What i have in mind is loading a table with the current version eg v501.1 and if the backend see a user logging in with v501.0 it will kick them out. (a little message saying why would be nice too).



Is this easy to set up?

thanks in advance.

[Welshgasman]

Normally it is the opposite. The FE starts and compares to BE, and if not current, updates itself?

Google bob larson auto fe updater.

[Micron]

They're keeping the fe open forever? If not, check for a new version at startup and don't allow them to open the old one. If yes, call a function on every form/report open to check and if there's a new version, cancel the opening. Some developers require user to use desktop shortcut which just downloads an new copy regardless of whether or not it is updated.

The risky part of kicking out users is that they might be in the middle of an edit, which might corrupt data if you force a close. Could have a way to check that they're not using unauthorized copies also, by checking the application path upon startup.

EDIT - agree with WGM; this is not handled by the be.

[Welshgasman]

I would check the path of the FE and also check it was an accde?

[Welshgasman]

https://btabdevelopment.com/free-access-tools/

[CJ_London]

think the problem you have is for the backend see a user logging in with v501.0, requires a modification to the FE code to tell the BE what version they are using - which apparently isn't happening for older FE versions

You could look at using a data macro to run some vba code in the backend to somehow lock users out. It would be triggered when the user adds/amends or deletes a record. So if you currently have a logging in process which appends a login time for a user to a table for example, you could run some code on that event. However I have no idea what that code would look like to achieve your objective. Perhaps latest FE populates another table with some value like machineID or username and the code checks to see this has had a current FE installed. If the user has connected with an old FE then this won't happen so your code would need to work this out.

[fishhead]

think the problem you have is for the backend see a user logging in with v501.0, requires a modification to the FE code to tell the BE what version they are using - which apparently isn't happening for older FE versions

You could look at using a data macro to run some vba code in the backend to somehow lock users out. It would be triggered when the user adds/amends or deletes a record. So if you currently have a logging in process which appends a login time for a user to a table for example, you could run some code on that event. However I have no idea what that code would look like to achieve your objective. Perhaps latest FE populates another table with some value like machineID or username and the code checks to see this has had a current FE installed. If the user has connected with an old FE then this won't happen so your code would need to work this out.

thanks for the ideas everyone.
I can see how the FE would be driving the version forced update process but what i have is a little different.
I have 1 user who has gotten his hands on an admin copy (more functionality) that i would like terminated each time he tries to run it. What i have in mind is currently his username/password and version information will be sent to the BE. I would like to know how to to tell the BE that if a specific version / user combination is seen to immediately close the FE with a message " old version please update " etc. Is there a way to have the BE close the FE for that particular user/version combination?

[CJ_London]

Is there a way to have the BE close the FE for that particular user/version combination?

you already have the answer - no because it requires a modification to the FE code. The BE cannot 'see' the FE it can only action on what the FE tells it by adding/amending/deleting records.

Suggest you modify your FE to have the functionality you require, link it to a new copy of the BE and distribute it to all users. Then rename the old BE as something else so the old FE's no longer work.

[fishhead]

thanks Ajax

[kd2017]

Thinking outside the box here... does the FE happen to make any updates to the BE when a user logs in? Like a last_login date field or something?

It might be possible to jury rig a BE table with a table macro that resets the users password or something... really just an inconvenience and not ideal but might encourage folks to stop using the wrong FE.

Ajax's post #8 sounds like the best final solution, disabling the current back end and forcing everyone to migrate to an updated FE/BE.

[fishhead]

Thinking outside the box here... does the FE happen to make any updates to the BE when a user logs in? Like a last_login date field or something?

It might be possible to jury rig a BE table with a table macro that resets the users password or something... really just an inconvenience and not ideal but might encourage folks to stop using the wrong FE.

Ajax's post #8 sounds like the best final solution, disabling the current back end and forcing everyone to migrate to an updated FE/BE.

YES.... there is an update to the BE when the user logs in. His user name and version with date/time stamp are recorded in a table on the back end. Can you show me how to kick the user out if a specific version is being used? This will fix my immediate problem of the user having access to functionality i don't want them to have access to.

I will definitely set something up which forces the users to use the most recent copy of the software in future (as this current problem has been a real pita......)

thanks,

[Micron]

His user name and version with date/time stamp are recorded in a table on the back end

Is this done via code or a macro? If code, need to see it.

[Minty]

Ajax's solution is the perfect and simplest method.
Simply change the backend name/location and release a new FE that works with that new BE only.

While you are at it change a single table name, that isn't used in too many places, and update the FE to that as well.
That way he would have to re-engineer the old FE to make it work, rather than simply relinking if he's clever enough to do that.

[Welshgasman]

TBH I would have one version of the FE, and login determines who is admin. If errant user gets that admin pw, change it.

[kd2017]

YES.... there is an update to the BE when the user logs in. His user name and version with date/time stamp are recorded in a table on the back end.

does it update the user table or some other log table?

Can you show me how to kick the user out if a specific version is being used?

well... no

Im not too well versed in macros but here is what I was thinking might be possible... (Big) *if* the table that contains the user's password happened to be being updated then it would have been possible to trigger some logic to delete that user's password. Doing this on the backend wouldn't end the current session for the user but keep from logging in later. This might be an annoying deterrent to discourage users from using the wrong FE.

But it sounds like your updating/inserting in a log table, this wouldn't be helpful in this regard.