How to transfer forms froms one database to a second.

  • Thread starter Thread starter Dan Neely
  • Start date Start date
D

Dan Neely

I'm doing my form design and testing in a separate copy of my database
from the one being used in production. What's the best way to get the
new versions of the forms combined with the data in the deployed
database.
 
Hi-

Select the form in the database window, then use File - Export. Navigate to
the dbtabase you want to save the form to, and click Save. You will be
prompted to overwrite the existing form, if it exists.

This can be used for any form or report etc.

It is not quite as simple as that if the new or modified forms depend on a
structural change in the data tables or queries.

John
 
It appears your real problem is you don't have your database split. The
proper way to deplay an Access application is to split the database. To do
this you use the Database Splitter. From the menu, Files, Database
Utilities, Database Splitter.
This will create two mdb files. One will be named whatever your current
mdb's name is. It is usually referred to as the front end. The other will
have _be appended to the name and know as the back end. The back end will
contain only data, indexes, and relationships. The front end will contain
all your forms, reports, queries, modules, and macros. The front end uses
the Linked Table Manager to link to the tables in the back end.

Put the back end on a server folder where all the users will have full
rights. Because Access creates and deletes and ldb file when it opens and
closes, full rights are necessary.

A copy of the front end should be on each user's computer. So each is
connected to the back end on the server, you should use UNC paths to link to
the back end rather than drive mapping.

Now, when you make modification to the "development copy" front end, you
don't have to worry about the data. You just redistribute the new version of
the front end to the users. There are a number of ways to do this, depending
on how automated you want to make it. It can be anything from an e-mail to
each user telling them to upgrade all the way up to a fully automated
automatic update.

It is also a good idea to convert the front end to an mde file of the front
end and distribute that to the users. An mde version cannot be modified by
the users and if correctly constructed, the cannot get direct access to the
data.
 
Dan said:
I'm doing my form design and testing in a separate copy of my database
from the one being used in production. What's the best way to get the
new versions of the forms combined with the data in the deployed
database.
Click to expand...


Split the data into two separate mdb files. Use one, called
the back end, for the tables and relationships. The other
one, called the front end, would contain all of your forms,
reports, queries, etc. along with links to the tables. See
http://allenbrowne.com/ser-01.html

This way, all you need to do to distribute a new version of
your forms and reports is copy the front end mdb file to the
user machines.
 
Marshall said:
Split the data into two separate mdb files. Use one, called
the back end, for the tables and relationships. The other
one, called the front end, would contain all of your forms,
reports, queries, etc. along with links to the tables. See
http://allenbrowne.com/ser-01.html
Click to expand...

Once I've done the split, how do I manually edit the links between the front
and back end files. My development machine and the machine where the
application is deployed are are on unconnected networks, so the paths coded
in when I split on my dev box will not be correct in the deployed location.
 
J_Goddard said:
It is not quite as simple as that if the new or modified forms depend on a
structural change in the data tables or queries.
Click to expand...

Is there any way to export table design changes, or do I still have to
manually reenter those changes on the production system?
 
DanNeely said:
Once I've done the split, how do I manually edit the links between the front
and back end files. My development machine and the machine where the
application is deployed are are on unconnected networks, so the paths coded
in when I split on my dev box will not be correct in the deployed location.
Click to expand...


Don't code any paths in the front end. Use the Link Table
Manager (Tools - Database Utilities) to create linked tables
in the front end. Then use a relinker procedure to
reconnect them after the FE is copied to a user's machine.
If all users will be using the same BE path, then you can
put a copy of the FE on the server, relink it and then copy
it to each user. Just make certain that users can not run
the FE copy on the server.

These might be useful:
http://www.mvps.org/access/tables/tbl0009.htm
http://www.granite.ab.ca/access/autofe.htm

Note: If the FE really does need to use the path to the BE,
it can be retrieved from any linked table's Connect
property.
 
Don't code any paths in the front end. Use the Link Table
Manager (Tools - Database Utilities) to create linked tables
in the front end. Then use a relinker procedure to
reconnect them after the FE is copied to a user's machine.
If all users will be using the same BE path, then you can
put a copy of the FE on the server, relink it and then copy
it to each user. Just make certain that users can not run
the FE copy on the server.
Click to expand...

Thank you. Is the reason not to run the FE on the server just
performance related, or due to some other issue.
 
Don't code any paths in the front end. Use the Link Table
Manager (Tools - Database Utilities) to create linked tables
in the front end. Then use a relinker procedure to
reconnect them after the FE is copied to a user's machine.
If all users will be using the same BE path, then you can
put a copy of the FE on the server, relink it and then copy
it to each user. Just make certain that users can not run
the FE copy on the server.
Click to expand...

Thank you. Is the reason not to run the FE on the server just
performance related, or due to some other issue.
 
Dan Neely said:
Thank you. Is the reason not to run the FE on the server just
performance related, or due to some other issue.
Click to expand...

Front ends should never be shared: each user should have his/her own copy.

Running a front-end from the network (even if it is a single-user front-end)
generates considerably more network traffic.
 
Front ends should never be shared: each user should have his/her own copy.

Running a front-end from the network (even if it is a single-user front-end)
generates considerably more network traffic.
Click to expand...

My question was if network traffic was the only reason a shared FE was
a bad thing, or if doing it the wrong way could cause other sorts of
problems as well.
 
Dan said:
My question was if network traffic was the only reason a shared FE was
a bad thing, or if doing it the wrong way could cause other sorts of
problems as well.
Click to expand...

The running FE updates itself (and irs related LFB file)
with status information and anything your code is modifying
(e.g. combo box RowSource) so there is a significant chance
of multiple users creating conflicts and at least getting
incorrect results and at worst corrupting the (one and only)
server's copy of the FE,

A few people have reported that they have made this
arrangement work, but I suspect that they have intuitively
done everything exactly right without even being aware of
the numerous pitfalls. OTOH, there are a myriad of reports
where a central FE frequently failed, crashed and been
corrupted.
 
Don't code any paths in the front end. Use the Link Table
Manager (Tools - Database Utilities) to create linked tables
in the front end. Then use a relinker procedure to
reconnect them after the FE is copied to a user's machine.
If all users will be using the same BE path, then you can
put a copy of the FE on the server, relink it and then copy
it to each user. Just make certain that users can not run
the FE copy on the server.

These might be useful:http://www.mvps.org/access/tables/tbl0009.htmhttp://www.granite.ab.ca/access/autofe.htm

Note: If the FE really does need to use the path to the BE,
it can be retrieved from any linked table's Connect
property.
Click to expand...
 
Don't code any paths in the front end. Use the Link Table
Manager (Tools - Database Utilities) to create linked tables
in the front end. Then use a relinker procedure to
reconnect them after the FE is copied to a user's machine.
If all users will be using the same BE path, then you can
put a copy of the FE on the server, relink it and then copy
it to each user. Just make certain that users can not run
the FE copy on the server.
Click to expand...

One more question. After the split how do I make it so my front end
can write to the back end instead of just reading.
 
One more question. After the split how do I make it so my front end
can write to the back end instead of just reading.
Click to expand...

Asked and answered. I was pointing to a read only copy of the backend
DB.

New question, without renaming/deleting the currently linked copy
though is there a way to change which DB is used as the backend?
 
Dan said:
Asked and answered. I was pointing to a read only copy of the backend
DB.

New question, without renaming/deleting the currently linked copy
though is there a way to change which DB is used as the backend?
Click to expand...


That's what the relinker code at the url I posted is
supposed to do. If you go to Google Groups I'm sure that a
search will find numerous threads on the topic, including
additional urls for variations of the relinker code I
suggested.
 
Back
Top