Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Database on Network.!
- Thread starter desprits
- Start date
Create a network share and give read write permissions to the share to whatever users need to use the db. Put the DB on the share.
[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]
[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]
desprits
Some research and planning to be done...
Here is a recent post that has some relevance to your query...
Consinder...
- topology (hardware design)
- presentation
- security - network
- security - within the database
- performance
- backups and maintenance (what do you do if the database does not work)
In an oridinary situation using an in-house local database, a common apporach is to use the Access wizard to split the tables from the forms.
All transaction tables would reside on the network. The application end (forms and reports), and perhaps static tables would either reside on each desktop or on the server. Desktop solution tends to be faster, the network solution requires less maintenance - only one front-end to roll out instead of rolling out to all desktop who use the application.
Some variations....
- You can have different front ends. HR would use a different front end where the forms display more sensitive information compared to a manager or supervisor who would only see the basic HR info.
- You can actually have two backend databases, one more secure than another. For the same reason provided in the aforementioned HR example. A little more complex, but is a neater solution for security.
TomThumbKP has provided one important thing required -- access. Note though that Access requires full rights to the directory. If you attempt to give somebody read-only access to the database, the Access database will complain very loudly. This is because Access uses various sytem tables to track "system things" (next autonumber, when a form was updated, record locking, etc). This is why I sometimes split the backend into two databases - one more secure than the other. NT and Novell security tends to be better than internal security within Access.
One more thing. I have indicated that "backups" should be part of your strategy. Before you invoke system changes such as splitting the database, and especially before invoking Access security or database replication, make a proper backup of the database first.
Richard
Some research and planning to be done...
Here is a recent post that has some relevance to your query...
Consinder...
- topology (hardware design)
- presentation
- security - network
- security - within the database
- performance
- backups and maintenance (what do you do if the database does not work)
In an oridinary situation using an in-house local database, a common apporach is to use the Access wizard to split the tables from the forms.
All transaction tables would reside on the network. The application end (forms and reports), and perhaps static tables would either reside on each desktop or on the server. Desktop solution tends to be faster, the network solution requires less maintenance - only one front-end to roll out instead of rolling out to all desktop who use the application.
Some variations....
- You can have different front ends. HR would use a different front end where the forms display more sensitive information compared to a manager or supervisor who would only see the basic HR info.
- You can actually have two backend databases, one more secure than another. For the same reason provided in the aforementioned HR example. A little more complex, but is a neater solution for security.
TomThumbKP has provided one important thing required -- access. Note though that Access requires full rights to the directory. If you attempt to give somebody read-only access to the database, the Access database will complain very loudly. This is because Access uses various sytem tables to track "system things" (next autonumber, when a form was updated, record locking, etc). This is why I sometimes split the backend into two databases - one more secure than the other. NT and Novell security tends to be better than internal security within Access.
One more thing. I have indicated that "backups" should be part of your strategy. Before you invoke system changes such as splitting the database, and especially before invoking Access security or database replication, make a proper backup of the database first.
Richard
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question