Splitting a database - The way forward?

[ant1983]

Hi,

I have broken my database into several stages. I have implemented the first
stage and this is simply the database (with basic features) on a central
computer and a shortcut added to each user's computer.

I know this is quite risky but at this stage only one person is cupturing
and editing the data and the rest is viewing information and printing reports.

I am still building on new features of the database and this would include
adding more fields to some tables.

1 - Could i now split my database and give each user a FE, given the fact
that i will still be adding and removing fields?
2 - If yes, what are the steps after i ammend the tables so that the Live
BE contains the ammended table structures?

Assistance would be much appreciated.

Thanks,

Wayne

 

[Rick Brandt]

Hi,

I have broken my database into several stages. I have implemented
the first stage and this is simply the database (with basic features)
on a central computer and a shortcut added to each user's computer.

I know this is quite risky but at this stage only one person is
cupturing
and editing the data and the rest is viewing information and printing
reports.

I am still building on new features of the database and this would
include adding more fields to some tables.

1 - Could i now split my database and give each user a FE, given
the fact that i will still be adding and removing fields?
2 - If yes, what are the steps after i ammend the tables so that
the Live BE contains the ammended table structures?

Assistance would be much appreciated.

Thanks,

Wayne

You will have to add code to the front ends that refresh the links to the
tables automatically at startup OR you will have to distribute new front
ends any tiem you change the design of the back end. The latter is more
common in corporate situations where replacing front ends is trivially
simple and the latter is more common in apps that are distributed remotely.

Note that the automatic refreshing of links can only deal with changes to
existing tables. When you need to add totally new tables then you will
almost certainly need new front end objects to interact with them in which
case distributing new front ends is the only viable option.

I would check out Tony Toews auto-update utility. It makes the distribution
of changed front ends totally automatic and something which the user never
even has to think about.

 

[Douglas J. Steele]

You will have to add code to the front ends that refresh the links to the
tables automatically at startup OR you will have to distribute new front
ends any tiem you change the design of the back end. The latter is more
common in corporate situations where replacing front ends is trivially
simple and the latter is more common in apps that are distributed
remotely.

Realistically, the fact that new fields are added generally implies new or
changed functionality. I'm hard pressed to imagine a case where strictly
refreshing the linked tables would be adequate. Replacing the front-ends
would strike me as being required in virtually every case.