Harlan said:
Matt,
No, there won't be problems with the back end if you do this..... BUT
REMEMBER, the copy of the front end will still be linked to the tables in
the back end unless you remove the links... so "data" changes WILL affect
the back end if you don't de-link those tables.
I usually IMPORT the tables into my "test" front end and delete the links
to the real back end... then after making all my changes to the front end,
delete the imported tables and reattach (re-link) to the correct back end
prior to deployment of the new front end.
Deleting the table links, and then importing that back end tables is a lot
of work, and is prone to many errors. With your suggestion after making your
changes, you then have to re-link back to the production back end, you now
have to DELETE ALL of tables. And, then have to link to each back end table
ONE BY ONE. (that is a LOT of work here).
Furthermore how are you going to distinguish between the many tables that
are often placed in the front end? Any Combo boxes or selection lists that
are not user changed should be placed in the front end. (why drag a table
over a network into the front end, when you can simply place the table in
the front and where it belongs -- this gives you much better performance as
for those tables and drop lists they do not need to be transferred or the
network).
The part that seems strange here is that after you delete all of the tables
you imported, you are suggesting to re-link to the back end (that means
re-link ONE TABLE AT A TIME to the back end). Many of my applications have
30, or even 50+ tables, and have to add back the table links one at a time
is a LOT of work. (perhaps it's just a typo on your part, and you didn't
really mean to suggest this process)
The suggested approach:
You make a copy of both the front end and the backend onto your development
computer. You then simply use the linked table manager, and link your front
to your "copy" of the backend. You're now free to develop new forms reports,
and modify or write new code for your application. You can even test
sensitive and dangerous code that deletes data, and once again you don't
want to do that on production data
Furthermore while most of your code will work with non linked tables,
testing debugging and developing an application with non linked tables, and
then simply changing it to linked tables in a production environment can
introduce bugs and code that will not function. For example the following
line of code works with local tables, but if you link the table the
following piece of code fails:
Set rst = CurrentDb.OpenRecordset("tablename", dbOpenTable)
if you use linked tables, the above must become
Set rst = CurrentDb.OpenRecordset("tablename")
or
Set rst = CurrentDb.OpenRecordset("tablename", dbOpenDynaset)
So, you can well see its a bad idea to write and develop code in a non
linked environment, and then all of a sudden deploy that code and
application that's not been tested with linked tables to all your users. In
other words as you develop, test, and write your code, any of the pitfalls
and problems that arise by using linked tables will be instantly noticeable
to you. With your suggestion, developers will not be working and writing
code with linked tables, and then your pushing out code into production
*with* linked tables. It means your code you write has not been battle
hardened or even tested by you in the final environment its going to be run
under.
So, it is suggested you use linked tables. When you finished make a few
changes, you simply take this front end, and now use the linked table
manager to link to the production back end. You then create the mde, and
deploy that to your users. There is no need to create the table links again,
or delete a whole bunch of tables, and then try to re-link one by one to the
back end...
While we're at this, the production front should be converted to a mde.
The other issue to point out here is the original poster said he can't work
on the front end while people are using it, and that means the front end is
being shared by MORE then one user (or is not being placed on EACH
workstation). That is a incorrect setup, and is not the recommended
approach, and one of the reasons why you split is so that you can have more
than one user in their OWN copy of the application that is placed on EACH
workstation.
