Updating split databases with tables, forms, etc

  • Thread starter Thread starter SRF Enterprises, Inc
  • Start date Start date
S

SRF Enterprises, Inc

I have just created a very basic database for my company that tracks work in
progress, collections, etc. Being the typical Beginner-to-Intermediate
user, I am dangerous in that I am willing to implement new found concepts
way before I know what I'm doing!

In this case, I have split the database, and frankly it is working very
efficiently in its current state of development. The Users each have a copy
of the FE on there computer, and the BE is on the"server" of a peer-to-peer
network. As an aside, the current Users are all "input clerks" with very
little computer knowledge - security not an issue.

Here is my challenge. Microsoft does a very good job of telling you how and
why to split a database, but I can find little or no information on how to
continue with the development of the database.

I have created a duplicate copy of the FE and BE in an entirely separate
computer, and I have been blissfully working away on improvements and
additions using the then current BE as dummy data. So far - no problem.

An example of the improvements is that I added a table to use as a look-up
in my "main database" of insurance agencies for a field that was previously
a simple data entry field thereby ensuring consistency. New table also
includes address, phones, etc. And of course, there is a related form,
addition to the Switchboard, etc.

Now I have a properly functioning original FE / BE and a separate database
with all of these improvements. But to my way of thinking, some of the new
stuff needs to go into the FE and some needs to go into the BE. Do I Copy?,
re-Split? re-Link? - I am so confused!!

I have only spent about 6 hours (2 hours if I knew what I was doing) on the
improvements, and I am more than willing to start over if necessary. And I
do understand that any attempts at merging will be to a backup (I'm not that
new)! : )

I would appreciate any and all assistance and suggestions. I truly enjoy
writing these mini-applications, as I am addicted to the art that you have
mastered. I am sorry if I am in the wrong forum, and I am equally sorry for
being long winded.

Thanks,
Bob in Tampa
 
SRF Enterprises said:
I have just created a very basic database for my company that tracks work in
progress, collections, etc. Being the typical Beginner-to-Intermediate
user, I am dangerous in that I am willing to implement new found concepts
way before I know what I'm doing!

In this case, I have split the database, and frankly it is working very
efficiently in its current state of development. The Users each have a copy
of the FE on there computer, and the BE is on the"server" of a peer-to-peer
network. As an aside, the current Users are all "input clerks" with very
little computer knowledge - security not an issue.

Here is my challenge. Microsoft does a very good job of telling you how and
why to split a database, but I can find little or no information on how to
continue with the development of the database.

I have created a duplicate copy of the FE and BE in an entirely separate
computer, and I have been blissfully working away on improvements and
additions using the then current BE as dummy data. So far - no problem.

An example of the improvements is that I added a table to use as a look-up
in my "main database" of insurance agencies for a field that was previously
a simple data entry field thereby ensuring consistency. New table also
includes address, phones, etc. And of course, there is a related form,
addition to the Switchboard, etc.

Now I have a properly functioning original FE / BE and a separate database
with all of these improvements. But to my way of thinking, some of the new
stuff needs to go into the FE and some needs to go into the BE. Do I Copy?,
re-Split? re-Link? - I am so confused!!

I have only spent about 6 hours (2 hours if I knew what I was doing) on the
improvements, and I am more than willing to start over if necessary. And I
do understand that any attempts at merging will be to a backup (I'm not that
new)! : )

I would appreciate any and all assistance and suggestions. I truly enjoy
writing these mini-applications, as I am addicted to the art that you have
mastered. I am sorry if I am in the wrong forum, and I am equally sorry for
being long winded.
Click to expand...

The "developer's advantage" of the split design is largely limited to the front end.
If you make changes to the data file then you face the same problems as a non-split
app; that is you need a period of time when all users can be kicked out and then you
need to pull all of the data from the current data file into the new one before it
can be returned to use with your new front end.

When you change only the front end (far more common), the data file is not affected
in any way so you just replace the user's current file with the new one and off they
go.
 
Back
Top