Splitting database - Back end loses directory path

[Guest]

I
Hello,

I am splitting an Access 2000 database to make a front end and a back end. I
am putting the back end (tables) in the same folder as the front end. The
problem is that I will need to send this folder out to the sales people and
when I move the folder the back end loses its directory path. Is there any
way to tell the front end to always look for the back end in the same folder
that the front end is in? The reason I want to do this is because none of the
sales people will be working off the network, they will all have there own
tables and this is a front end that I will continually have to be updating.

 

[Joseph Meehan]

I
Hello,

I am splitting an Access 2000 database to make a front end and a back
end. I am putting the back end (tables) in the same folder as the
front end. The problem is that I will need to send this folder out to
the sales people and when I move the folder the back end loses its
directory path. Is there any way to tell the front end to always look
for the back end in the same folder that the front end is in? The
reason I want to do this is because none of the sales people will be
working off the network, they will all have there own tables and this
is a front end that I will continually have to be updating.

I am not sure you should be splitting this database.

The usual reason for splitting a database is because data needs to be
shared by a number of users who share a LAN. The back end is placed on the
"server" and the front ends located on each users machine. Normally the
front end and back end would not be in the same location.

If your sales people do not share the same server and if the the data
needs to be shared, then replication is the tool of choice.

If I am wrong, then let me suggest that normally the front end is put on
each user's machine and since the path is often different for different
users on the same LAN, some may need to re-link the tables.

 

[mcnewsxp]

you'd have to make sure the *full* path is the same.
easiest way to put in a folder off the root.

 

[Douglas J Steele]

I am not sure you should be splitting this database.

The usual reason for splitting a database is because data needs to be
shared by a number of users who share a LAN. The back end is placed on the
"server" and the front ends located on each users machine. Normally the
front end and back end would not be in the same location.

If your sales people do not share the same server and if the the data
needs to be shared, then replication is the tool of choice.

If I am wrong, then let me suggest that normally the front end is put on
each user's machine and since the path is often different for different
users on the same LAN, some may need to re-link the tables.

Actually, I split all of my applications, whether they're single-user or
not, and my single-user applications usually have both parts in the same
folder. Just because it's single-user doesn't mean there aren't multiple
users using the same application: they're just not updating the same
back-end.

The same reasons for splitting apply: you can change the front-end to give
new capabilities without impacting the user's data.

You could be correct that replication is appropriate in this situation, but
that doesn't preclude the need to split the application before you
replicate: replication is only intended for the tables, not any other
objects.

 

[Joseph Meehan]

Douglas J Steele wrote:
....

....

The same reasons for splitting apply: you can change the front-end to
give new capabilities without impacting the user's data.

That is a good reason to split an application for a single user. I am
not at all sure most people should use it as standard practice, but that is
only an opinion and in some areas it may well be a good idea. Splitting for
this reason should normally not cause an problems and I see no reason not to
do it. BTW I included my quote " I am not sure you should " because I was
aware that there are some good reasons. However, a casual reading of my
message could well have left the impression other than what I intended.
Thanks for clearing that up.