Lize said:
Can someone advise me what to do with additional development after a
database
has been split and several front ends are in use?
I explain in details what you have to do in the following article of mine
here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
However to save you having to read the above whole article, the general idea
is that you'll go into the back end database, add the new table.
You then go into your front end database, and then use file->get external
data->, link tables
You then browse to the back end mdb file, and then link this new table. As
Noted in my above article, make sure you use universal naming conventions
for path name to the back end so that uses a new network will not have a
problem when you deploy the new front and to each user (unc path names are
again explained in detail in the above split article if you don't know what
this means).
I want to develop a new table and form in my existing accdb after this has
been split for a year, however not sure where to develop this table and
create the relevant form (front end or back end?) and how to make sure
this
newly developed table and form are linked from front end - back end and
vice
versa?
Keep in mind that we often develop applications off site. In fact what this
means is that often you'll be developing and testing your software on a copy
of the backend database AND the front end. Thus is really nice since then
during the development process you are to free to enter test data, delete
records, enter junk into the database, and not worry about damaging or
playing with the actual real production data that's so important to your
organization. As a developer I find it very hard to tippy toe around real
live data that's in use by everyone. So work on both a copy of the front end
and the backend. I can then play around and even test dangerous deletion
routines or enter junk with without any fear of damaging valuable data, it's
kind of like the idea try to work on an airplane with passengers in a while
you're flying, versus it's sitting in the garage where you've totally free
to test all kinds of things without serious consequences if you make a
mistake.
So, if you make changes to the back end (such as adding new fields), or in
your case adding a new table, then when I do is start a little note pad
document on the list of changes I'm made. The notepad document will look
like this:
add new column Location (text 25)-- > to table customers
copy new table called MeetingDates
etc etc.
In the above you can see my notes that I added a new column called location
to table customers in my test copy of the development back end system
(remember I have a copy of both the backend database, and the front and
program on my test development machine). So as I develop along, if I make
any changes to the back end database table(s), then I make an entry note in
a small notepad document of what I done.
Then when I am ready to deploy the production database, I have to have
everybody stop working for at least a little bit of time. (you might send
out a company memo, or simply schedule certain amount of downtime when
you're ready to the ploy this new update to your users). You then open up
the production backend database directly. You now look at your notepad
"list" of changes you made and quickly knock off each little changes made in
that list to the production database. So from the above example I open up
table customers in design mode, and add a new column called location as a
text column of 25.
I then need to add the table called meetingDates. While in this production
backend database, I will then use a file get -> external data and import the
new table I created called MeetingDates from the development back end. You
could also just create a new table from scratch and manually add the columns
to this table. However, it usually better to import the whole table with all
the indexes and column names and everything else already set up (and you
have this table in your testing/development back end...so, you might as well
use it). Copying in the table makes less mistakes then recreating the table
from scratch. So, once I've modified and added the new column to the one
table, and also added the additional tables I've created, you then ready to
deploy you new version of your software.
So, you then link your new front end to the production back end (that was
previous linked to the testing and development back end). You then create a
mde, and it is this mde that is then distributed to all of your users
desktops.
also choose taking a quick Kim of your question, but, I noticed that you're
using access 2007, so in my above comments where I talk about a mdb, I mean
a accDB in your case, and where I talk about a mde, I mean a accDE in your
case.
a cinch are using access 2007, there's no file get external data, but in the
ribbon there's the external data tab, and the process is much the same as
above we simply choose to link a table. So, the linked table manager is used
to change what back and you're pointing two, but the external data tab is
used to add one additional table to your front and after you've added the
table to your back end database.
