Adding Tables, Forms, Data etc to Split Db

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

NOYB - 18 Sep 2003 12:49 GMT

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

Reply to this Message

Albert D. Kallal - 18 Sep 2003 20:53 GMT

> 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.

Yes, this works well, as you can now work away on new changes to the system,
and you users can continue to work also. Without splitting, this would be
impossible.

> 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.

Well, making changes to the front is easy, since you will be re-distribution
a new front end to the users. (note how this again a HUGE improvement over
trying to figure out what you changed, and somehow import this into a
existing non-split mdb. It would be just nearly impossible!).

Now, anytime you make a change to the back end, you either must:

Make the same changes to the production back end, or
Make some notes of exactly what you changed in your back end, so when
you kick all your users out to be upgraded, you will also make the same
changes to the back end.

However, since you are only adding new tables, and perhaps some new fields,
that is MUCH MUCH easier to keep track of then a zillion changes to forms
and code!

> 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!!

You do whatever you find the best. For example, if you added a few tables to
your test back end, then you can simply import those new tables to the
production back end (that is easy). If you just added a few new fields to a
existing table in the back end, then of course you can't import the changes,
but must manually go into the production back end and make those changes.

As for adding new tables...well of course you add the new table in the back
end, and then on the font end go new-table->link.

So, basically I start a text document, or even a word doc. Any time I add a
new field, or a new table to my test back end, I will write:

added new lookup table tblColors
added new field favorateColorId to tblCustomers.

etc.

Now, when I am ready to upgrade the back end, I just take a look at my work
doc. And go,..ah yes..I added a new table.I just import that table from the
test back end into the production back end.

Ok, now...ah yes...added a new field to tblCustomers. In that case I file
fire up two copies of ms-access, pop the test back end into design mode for
that table, LOOK AT THE field I added. I the fire up the the production back
end and bring up the same table into design mode. I then type in the new
field name. The reason why I fire up both back ends is that I want to make
sure that the field I add is EXACTLY the same type of field, and EXACTLY the
same name.

Often, this means I have 3 copies of ms-access running at the same time.

So, the only really hard part is when changes are made to the back end. You
don't have to keep track of changes in the front end, so it is not bad a
all.

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Reply to this Message

Bob Loder - 19 Sep 2003 21:53 GMT

Thank you so much for your input and patience. (this is still me - I've
change my user name to real name for friendliness sake).

I fear that I have botched this datbase up so bad, that I am going to start
over again - from the time I split the database. It is well worth the
insight that you have provided. My botching came from "willy-nilly" copying
/ pasting / drag n dropping / and my code has disappeared! I totally
ignored the backend database and added new tables, new fields, changed text
fields to lookup fields in tables with data coming from new tables. I
somehow deleted my switchboard, and I can't create a new one - sometimes
lifes lessons are hard, but I have learned - and that's a good thing.
Intuitively I wonder if a split database can be "unsplit" - but I'm not
certain to what advantage except when I realized my "improvements where
predominantly (but not consistantly) on the wrong side of the split -
unsplitting - settling it down - re-splitting (if such a thing existed)
would have gotten me out of trouble.

Thanks,
Bob Loder
a/k/a Bob in Tampa

> > 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
[quoted text clipped - 74 lines]
> kallal@msn.com
> http://www.attcanada.net/~kallal.msn

Reply to this Message