40,000 records table as back end with 6 front end users
- Thread starter DavidCdp1
- Start date
As far as the number of records is concerned I am working on a db at present with 32,000 records with no probs regarding speed.
You should be extra careful in designing your queries, though, consdering possibilities of more than one user accessing data, volume of traffic on the LAN etc.
You should be extra careful in designing your queries, though, consdering possibilities of more than one user accessing data, volume of traffic on the LAN etc.
The answer is Yes.
I have worked on databases whith much greater volumes of data then this with no problem.
Are your six front ends the same but for six different people, or do they do six different jobs?
If they are the same you can just have one on the server and let everybody use it, access does allow multiple users for the same database, but you can't develop it while anyone else is using it.
If network traffic is an issue, then the front end can be copied out to the various users to keep on their own P C's. This allows you to develop the master version, but you then need to keep a track of revisions, and have a system for making sure everyone is using the latest versions.
If the front ends are all for different purposes, then you just create the ones you need and link to the back end as normal.
I have a system where 1 user needs access to everything, but other users need a use a restricted number of forms, and should not see other parts of the database.
To cope with this and ensure that the forms in both places are the same, I have created a master front end with all the forms, and referenced this from the other front ends.
In the master I have written a module with public subs to open each of the forms needed by the other front ends.
In the other front ends I have written a module to call the subs from the master, and I access these using a switchboard.
Thus the users see their own switchboards, and click the buttons to use the forms they require. The forms are actually those on the master frontend so changes made to the master are always seen immediately by the other front ends.
I find this give me the flexability to show users only wht they need to see, but reduces the problems with keeping versions in step accross the system.
Of course if all of the front ends do completely different jobs, what I have just said is irrelevent!
Sue
I have worked on databases whith much greater volumes of data then this with no problem.
Are your six front ends the same but for six different people, or do they do six different jobs?
If they are the same you can just have one on the server and let everybody use it, access does allow multiple users for the same database, but you can't develop it while anyone else is using it.
If network traffic is an issue, then the front end can be copied out to the various users to keep on their own P C's. This allows you to develop the master version, but you then need to keep a track of revisions, and have a system for making sure everyone is using the latest versions.
If the front ends are all for different purposes, then you just create the ones you need and link to the back end as normal.
I have a system where 1 user needs access to everything, but other users need a use a restricted number of forms, and should not see other parts of the database.
To cope with this and ensure that the forms in both places are the same, I have created a master front end with all the forms, and referenced this from the other front ends.
In the master I have written a module with public subs to open each of the forms needed by the other front ends.
In the other front ends I have written a module to call the subs from the master, and I access these using a switchboard.
Thus the users see their own switchboards, and click the buttons to use the forms they require. The forms are actually those on the master frontend so changes made to the master are always seen immediately by the other front ends.
I find this give me the flexability to show users only wht they need to see, but reduces the problems with keeping versions in step accross the system.
Of course if all of the front ends do completely different jobs, what I have just said is irrelevent!
Sue
Similar threads
