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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Using Access on Network
- Thread starter Zahir
- Start date
I would suggest using MS SQL Server 7.0. You can use Access 97 as a front end and have your objects stored on SQL server. You can access SQL server through an ODBC connection you set up through the control panel of NT or 95. Once your ODBC connection is set up link whichever tables you are working with and wa-la...done.
- Thread starter
- #3
ALA02,<br>
<br>
i dont need to use SQL Server because my application is for teo or three users and my client don't want it.<br>
<br>
i like to solve it in Access only.<br>
<br>
<br>
if u can help me on this regards pls give me favour ..<br>
<br>
<br>
<br>
<br>
i dont need to use SQL Server because my application is for teo or three users and my client don't want it.<br>
<br>
i like to solve it in Access only.<br>
<br>
<br>
if u can help me on this regards pls give me favour ..<br>
<br>
<br>
<br>
Building on Lehtoant's comments...<br>
<br>
One option is to split the db into front end (forms etc.) and back end (tables). The back-end db could be on the file server and the front end could be on the desktop. This will improve network performance because forms won't have to be transmitted over the wire. However, you will have the headache of distributing the front-end to your clients, keeping them up to date etc.<br>
<br>
There is no reason why the entire db (unsplit) can't sit on a network drive. Clients access the db as if it were their own. This should be okay if the db is not to big and the number of users is not to great and it is not a critical application. If any of the above is true, you really SHOULD be using another tool/tool-set.
<br>
One option is to split the db into front end (forms etc.) and back end (tables). The back-end db could be on the file server and the front end could be on the desktop. This will improve network performance because forms won't have to be transmitted over the wire. However, you will have the headache of distributing the front-end to your clients, keeping them up to date etc.<br>
<br>
There is no reason why the entire db (unsplit) can't sit on a network drive. Clients access the db as if it were their own. This should be okay if the db is not to big and the number of users is not to great and it is not a critical application. If any of the above is true, you really SHOULD be using another tool/tool-set.
In answer to your original question, the front end communicates with the back end through Access's linking mechanism. To link manually, open your front end (containing all onjects except tables), click on File/Import external data/link, browse to your back end (containing only tables), and select all. When the process is complete you should see icons indicating linked tables (arrows indicate the links) appear in the tables tab of your front end.<br>
<br>
If you are going to put this on the server, and your users use a different drive letter to map to the folder that you use, you can relink using the virtual address. Click on Tools/Add-Ins/Link Manager, select all and click on the checkbox at the bottom, click on the Advanced button and key in the path (beginning with
<br>
If you are going to put this on the server, and your users use a different drive letter to map to the folder that you use, you can relink using the virtual address. Click on Tools/Add-Ins/Link Manager, select all and click on the checkbox at the bottom, click on the Advanced button and key in the path (beginning with
- Status
Similar threads
- Locked
- Question
- Locked
- Question