Splitting an Access Database

[Guest]

Hi Guys,

I am playing around with "splitting" an Access database and it works fine.

I have a question....when you split the database, you are asked to specify a
folder that the database containing the tables is to reside. For example, if
I specifiy c:\tables then the Splitting utility will place the database in
this folder.

If I then double click my original database it will use the tables located
in the c:\tables folder...so far so good.

My question is this, where is this path/folder information stored and can I
change it so that once I split a database I can then "maually" and easily
change the name of the path/folder containing the tables?

Thanks for any help you can provide.

Regards
Greg

 

[RoyVidar]

Hi Guys,

I am playing around with "splitting" an Access database and it works
fine.

I have a question....when you split the database, you are asked to
specify a folder that the database containing the tables is to
reside. For example, if I specifiy c:\tables then the Splitting
utility will place the database in this folder.

If I then double click my original database it will use the tables
located in the c:\tables folder...so far so good.

My question is this, where is this path/folder information stored and
can I change it so that once I split a database I can then "maually"
and easily change the name of the path/folder containing the tables?

Thanks for any help you can provide.

Regards
Greg

In the Tools menu, Database Utilities, you'll find the Linked Table
Manager.

You can also play with it in code, for instance using the .Connect
property of the DAO tabledef object.

 

[Guest]

Thanks Roy

If I split the database and put the tables into a folder called c:\tables
and then load the databases onto another PC that has only the Access runtime
and want to move the tables database onto a network drive (eg: g:\tables),
how can I do this?

Thanks Greg

 

[Joan Wild]

Copy the tables onto the server. Use linked table manager to refresh the
links. Then distribute the frontend to the other computers (the link is
stored in the frontend).

 

[Albert D.Kallal]

If I split the database and put the tables into a folder called c:\tables

and then load the databases onto another PC that has only the Access
runtime
and want to move the tables database onto a network drive (eg: g:\tables),
how can I do this?

Since you as a developer had to ask about the linked table manger, we can't
possibility expect users to be trained on how to use/find this utility.

So, most of us roll our own re-linking code. The code checks for the back
end..and if not, then we pop up the file browse dialog, and have the user
select a back end..and then re-link. this is a FAR FAR more user friendly
approach then teaching users about the linked table manger.

Further, in the runtime, we don't have the linked table manger anyway.
However, as a ms-access developer, you will likely figure out LONG LONG
before you deploy a runtime application that you need to roll your own
re-linking code.

So, build your own re-link code. It solves the issue of having to teach
users about using the linked table manager, and it FURTHER solves issues
since with the runtime you don't have the linked table manager. So, by
building your own, you solve several problems at at once.

The code to re-link tables can be found here:

http://www.mvps.org/access/tables/tbl0009.htm

And, the code to popup the file browse dialog can be found here:
http://www.mvps.org/access/api/api0001.htm

So, between the two above routines, in a short time you can cobble together
some code that can re-link for you.

So, the end result of your efforts is

* It is more user friendly

* Users can relink tables even with the runtime

* You code now will check for tables in the back end, and ask to
re-link...again saving valuable support calls/dollars.

To check for the back end...just open any table, and trap the error....

You can also use the dir command to check for the existence of the back end
(I prefer this approach over that of testing/trapping an attempt to open a
table).

 

[Guest]

Thanks Albert

Regards
Greg

Since you as a developer had to ask about the linked table manger, we can't
possibility expect users to be trained on how to use/find this utility.

So, most of us roll our own re-linking code. The code checks for the back
end..and if not, then we pop up the file browse dialog, and have the user
select a back end..and then re-link. this is a FAR FAR more user friendly
approach then teaching users about the linked table manger.

Further, in the runtime, we don't have the linked table manger anyway.
However, as a ms-access developer, you will likely figure out LONG LONG
before you deploy a runtime application that you need to roll your own
re-linking code.

So, build your own re-link code. It solves the issue of having to teach
users about using the linked table manager, and it FURTHER solves issues
since with the runtime you don't have the linked table manager. So, by
building your own, you solve several problems at at once.

The code to re-link tables can be found here:

http://www.mvps.org/access/tables/tbl0009.htm

And, the code to popup the file browse dialog can be found here:
http://www.mvps.org/access/api/api0001.htm

So, between the two above routines, in a short time you can cobble together
some code that can re-link for you.

So, the end result of your efforts is

* It is more user friendly

* Users can relink tables even with the runtime

* You code now will check for tables in the back end, and ask to
re-link...again saving valuable support calls/dollars.

To check for the back end...just open any table, and trap the error....

You can also use the dir command to check for the existence of the back end
(I prefer this approach over that of testing/trapping an attempt to open a
table).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.members.shaw.ca/AlbertKallal

 

[harleyken]

Where would I put the code you ref?
Thanks
Ken

Since you as a developer had to ask about the linked table manger, we can't
possibility expect users to be trained on how to use/find this utility.

So, most of us roll our own re-linking code. The code checks for the back
end..and if not, then we pop up the file browse dialog, and have the user
select a back end..and then re-link. this is a FAR FAR more user friendly
approach then teaching users about the linked table manger.

Further, in the runtime, we don't have the linked table manger anyway.
However, as a ms-access developer, you will likely figure out LONG LONG
before you deploy a runtime application that you need to roll your own
re-linking code.

So, build your own re-link code. It solves the issue of having to teach
users about using the linked table manager, and it FURTHER solves issues
since with the runtime you don't have the linked table manager. So, by
building your own, you solve several problems at at once.

The code to re-link tables can be found here:

http://www.mvps.org/access/tables/tbl0009.htm

And, the code to popup the file browse dialog can be found here:
http://www.mvps.org/access/api/api0001.htm

So, between the two above routines, in a short time you can cobble together
some code that can re-link for you.

So, the end result of your efforts is

* It is more user friendly

* Users can relink tables even with the runtime

* You code now will check for tables in the back end, and ask to
re-link...again saving valuable support calls/dollars.

To check for the back end...just open any table, and trap the error....

You can also use the dir command to check for the existence of the back end
(I prefer this approach over that of testing/trapping an attempt to open a
table).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.members.shaw.ca/AlbertKallal

 

[Albert D. Kallal]

Where would I put the code you ref?
Thanks
Ken

If we don't know where to put code, I afried it going to be dififclt for you
to start writign some code to use those exmaples! It is assumed that if your
cutting and pasting code from exmaples, you will need at least basic skills
of using code, and where it goes.

If you want to see an example of code that uses the file open API, then try
downloading my "shift key" example here:

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

So those code samples would be placed into a standard code module that you
create. I would suggest that you consider getting some book on MS access
that has some introduction on writing code. Asking were the code goes is
like asking me how do you plug in a power saw that I just handed you to cut
a piece of wood.

So, standard code modules is just about where all of the code samples you
use will occur. of course some code steps and examples on the following site
will be placed in your form if its code that goes behind a button for
example. So, check out the following site as it has absolute boatloads of
sample code you can use in your the application. In fact, it has code
samples that can be used to solve just about EVERY conceivable access
problem you will encounter, and they are organized by "forms", "reports",
etc on that site.

that side is here:

http://www.mvps.org/access/

You REALLY do want to book mark this site, as it is a gold mine.

 

[harleyken]

I have that (and several other) sites bookmarked! just was unsure if the
code was ment for a form or module. I try to understand what the code does
[before] I use it, but for mere mortals there is so much to know... thanks
for the help (and your articles.)
ken

 

[BC]

I'm sure others will benefit from the code you posted, however I don't
understand why you chose to reply to his question in such a condescending
way. His not knowing where that code belongs does not necessarily mean he is
without basic coding skills. Maybe he uses Visual Studios, but he has had
limited experience with Access.