1 of 1 people found this helpful
The difference are the scripts and the layouts. So, you need to copy the layouts and scripts back to the data file. I've never done this before but since the tables and fields have the same names, it should be tedious but straightforward. Some things may need to be reconnected like layout references in scripts but give it a test run and see.
I personally never use the separation model as it creates too many difficulties in the development process versus the benefits it provides.
You created separate files not separate tables within a file.Also within the files you have separate tables. Much easier if you only have one table per file. I guess this would be a form reverse engineering.
if you only have one table per file then pick a file to become the new database, import the tables and build a relational graph. Before you do this it is important to graph out your work on paper including your relations, ids, etc.
If you have multiple tables in the files bigger headache take paper and pencil and work out all you relations, etc. Then begin importing data.
You should employ some developers tools such Base Elements
I did this once on a database I was working on. It was not fun.
I am sure someone else has a better suggestion.
Thanks for mentioning the layouts. I forgot about them.
Thanks Jaimo and Patricia
..Well, this looks like a lot of work, which in our case can be avoided since we still have the "Unseparated" application saved !
Seemed to us that providing the data design is stable, (which is a big question, since many clients ask for things that require changes here) being able to work on the UI independently from the data is a good thing. Any further comment from you on this would be welcome, since we have an opportunity at this point to leave the data-separation thing alone for a while..
Hi Patricia..Are you saying there is some advantage to having only one table per file? Your comment on this would be helpful...
We have only one file, which has over 100 related tables, not counting the additional table occurrences for UI purposes..
Have you tried separating data from the UI (script & layouts) yet?
One table per file? I don't get it. For some solutions this could mean hundreds of files.
I just answered your other question, Norm.
I don't know if Patricia is actually advocating for one table per file. I hope not.
Here's the basic process for moving code, usually applied to separating UI/data, but works pretty much the same in reverse:
It's not rocket surgery, it's just as Jaymo said, tedious.
Hmm! Takes my mind back to FM5.
The first step I would do is get a current Database Design Report and maybe some other anlicizing program.
Depending on the amount of data I would look at putting data tables into my UI to minimize the number of layout that need to be copied But I see there are possible problems with either method.
1 of 1 people found this helpful
I am not recommending one table per file I was looking at various ways Norms Database could have been designed. Though if the situation called for only one table in a file than there is nothing wrong with it. We design to meet needs.
Yes, I have done UI which was separated from the data files. If you already have a database that is functioning, I would not shake the boat. All the suggestions are excellent including the check list mentioned by Tom on Todd Geist site. But with such a large number of tables it is is easy to make a mistake.
There are quite are articles the separation model and discussions on the this web site. Read them. ESM has an excellent discussion on managing separation model. Learn how to work with it. There are developers who prefer the separation
Unless you have a strong reason for making the change I would not.