My Access si split into a front-end containg everything but the tables, and a backend containing only the tables. The tables in the front end are linked to the backend. Both reside on one server.
So far I can have up to 15 concurrent users.
I need help with the procedures and a strategy for coding when I want to modify an object property for each individual user. For example, I want to change the background color of a control when an error occurs.
If I change the control property, it will affect all users.
The front end should be distributed among all of your client machines as opposed to a single shared copy on the server. Making it a shared front end sort of defeats the purpose of seperating the front and back end to begin with.
However, if you MUST have a single shared copy, you could create a txt file that would reside on each clients computer and have the front end reference that file for a list of preferences onload.
What I still don't understand is that each workstation would either need it's own copy of the front end or preferences file. Does that mean that each time I implement a change I need to implement it on each and every workstation?! The most efficient way I can thing to do that is to implement the changes on the "master" front end residing on the server, save/delete each front end on every workstation, and then copy the "master" front end to each workstation. To do this for 15 workstations is time consuming enough. Would it still be done this way if there were 100 workstations? What am I missing here?
I agree the splitting of the DB with both pieces residing on the same server defeats the purpose. This is how the DB was set up prior to my arrival. If there is no system benefit, do you know if there is performance degredation as a result? Ifso we might as well go back to the old way.
...The most efficient way I can thing to do that is to implement the changes on the "master" front end residing on the server, save/delete each front end on every workstation, and then copy the "master" front end to each workstation.
I have a few client front ends that I am currently maintaining. I took a similar approach to what you are describing while adding a few tweaks. Essentially there is a master front end, the current version, residing on a shared directory. Then on each client machine, there is a folder containing all of the client-side front ends, and preference lists. When the user loads the front end, it checks the created date timestamp of the version the client has to the most current version on the server. If the version on the server is newer, it instructs the user to run an "update" program that is also server side. Then it terminates the front end. The user runs "update programs" which copies all of the current versions to their local machine and they're off.
I agree the splitting of the DB with both pieces residing on the same server defeats the purpose. This is how the DB was set up prior to my arrival. If there is no system benefit, do you know if there is performance degredation as a result?
My experience with splitting the an access database into front/back ends has been terrible.
For one thing, access is slow enough when accessing a .mdb over a network, but when you also include the fact that linked table performance is slow and all your tables are linked to the back end, performance really wreaks.
I've had form loading time increase dramatically when the back end is over the network as compared to a local back end. The time it took to load my form over a network when the database is split went up to several seconds, as apposed to the same form opening without noticeable delay when the backend was on my local machine.
Another thing about concurrent users and .mdb's is that the more users which have the same database open, the more likely that database is to get corrupted. This is a real issue, and if you plan on having multiple users in the database, expect to become an expert in fixing corrupt .mdb's, even when you make FREQUENT backups.
Also, if you change the properties of a control via VBA code, those changes will not effect other users unless the form is saved afterward. If that's a worry, you can set the properties in question to their default values in Form_Load, so that even if the form is saved with the incorrect property values, it is reset again each time the form is opened.