To put the story short, I took over the upkeep and developer for our fmp database. Problem was, from the start, my boss built the database we use as he went. Lots of residual fields and tables and scripts that are still unused.

Its a mess, and the worst kind of mess, one that would take months to fix. Only, we tried for the past few months to have me do what i can. I've reached the point where its so hard for me to fix these old issues because everything is a rats nest on the back end so to speak (Take a newbie to fmp, one with only moderate programming knowledge, and even less experience with user interfaces, and have him build your production database while it is in production! badddd news!)

Anyway, our current databases are all messed up. I've been assigned the task of redoing our entire database using the separation schema: data in one database, and layouts in the other database. This way one can easily build a totally new front end without ever having to disrupt the production environment whatsoever!

What tips does anyone have for taking an existing screwed up database, and rebuilding it from scratch. Not only the backend, but also rebuild the entire front end.

(This database will be used to track inventory, service contracts, contacts, quotes, orders, engineering tickets, etc etc - the usual stuff for a tech company)

Thanks a bunch!!!

Cassetti:

You've got quite a job in front of you, but also a great opportunity.

You'll be able to fix anything that's broken, streamline anything that's difficult to deal with, and migrate up to FM8 at the same time. Those are the good things. The problem is, you'll be rewriting the whole thing, so you'll be at it for quite some time.

The way I deal with this kind of situation is to take the old system and print out every kind of data you can print out for it - field definitions, value lists, layouts, relationships, and a few sample records, from every file. Then I go through all of those things by hand and mark up what needs to go, what needs to stay, and what needs to be changed.

From those marked-up printouts I can begin building the new system in FileMaker 8. When you get to this point, it becomes easier to move forward than when building a new system from scratch, because so much of what you need to do is right there in front of you.

One very important thing to keep in mind is the migration strategy for the actual data. You must be sure that you will be able to actually get the data into the new system - this is one reason I print out sample data from each file, so that I can see what the data looks like, and see where the data will come from, relative to where, in the new system, it is going to end up.

As I said, it's going to be a long job. Good luck with it.

-Stanley

Definitely true - I'm very excited about this opportunity to built this database to be functional and fill everyone's needs for a better interface

Very good idea on printing out as much as i can, i'm going to do that when i get to that stage in the process

Thanks for the good advice.

Anyone else have any advice for interfaces? I'm going to take all databases, and design all layouts pretty much from scratch.

Do you guys think that i should install sample databases and view how they organize inventory databases and contact databases?