Jump to content

  •  

Photo

Separating interface and data


  • Please log in to reply
5 replies to this topic

#1 StefanV  newbie

StefanV
  • Newbies
  • PipPip
  • 2 posts
  • FM Application:11 Advance
  • Platform:Windows 7
  • Skill Level:Intermediate
  • Membership:TechNet

Posted 25 June 2011 - 06:26 AM

Hi, while I'm new to FM, I am experienced in "older" database programming. So "only" the interface is new to me.

I've written an application and we could start data entry. As I will keep on developing the interface, I need a (easy:) way to update the application while keeping the existing data intact after.

From my research, it looks like I should separate my interface files and data files. But by now I have 48 tables in my application with many more TOs and relationships. So I looked if I could copy the whole file and relink the interface from one application to the databases of the other. While I can import the other "external" databases, that leaves me without relations on the new files, and the existing application remains on the "original" databases with all the layouts linked to the wrong (original) files.

Is there a good way of separating the two, or do I have to start back from scratch, which would be discouraging after this much work.

Or,... Keeping both data and interface in one file, can any one get me going on a script that would allow the data-update from the "old" file? I hear its all about "copy all data from old file to new file" and "update the counters for automatic field entry". Any more pitfalls I need to be aware of?

Thanks,
Stefan
  • 0

#2 bcooney  consultant

bcooney
  • Moderators
  • 5,764 posts
  • LocationLong Island, NY
  • FM Application:13 Advance
  • FMGo:iPad
  • Platform:Cross Platform
  • Skill Level:Expert
  • Certification:9, 10, 11, 12
  • Membership:TechNet
  • Time Online: 23d 10h 57m 44s

Posted 25 June 2011 - 10:05 AM

This approach is called within the FM community, the "Separation Model." It has a forum devoted to it here. Some swear by it, others not so much.
  • 0

#3 Vaughan  Mostly Harmless

Vaughan
  • Moderators
  • 10,294 posts
  • LocationSydney, Australia
  • FM Application:13 Advance
  • FMGo:iPhone / iPod Touch, iPad
  • Platform:Cross Platform
  • Skill Level:Expert
  • Certification:8, 9, 10, 11
  • Membership:TechNet
  • Time Online: 4d 9h 48s

Posted 25 June 2011 - 03:13 PM

Some swear by it, others not so much.


Some swear AT it. :D
  • 1
Vaughan Bromfield
Sydney, Australia

Please post questions to the Forum, not directly to me. Back-up your files before making changes!

Whenever I hear the term "popular culture" I reach for my Iridium Q-36 Space Modulator.

#4 IdealData  IdealData

IdealData
  • Members
  • 2,613 posts
  • FM Application:12 Advance
  • Platform:Mac OS X Snow Leopard
  • Time Online: 8d 19h 45m 46s

Posted 26 June 2011 - 01:37 AM

Or,... Keeping both data and interface in one file, can any one get me going on a script that would allow the data-update from the "old" file? I hear its all about "copy all data from old file to new file" and "update the counters for automatic field entry". Any more pitfalls I need to be aware of?


That's the way I do it. The separation model is great in many ways but often I find that I am updating the table schema and the interface to achieve new functionality so the separation model gains me little as I still have to import records from the data file any way.

1. If you are storing containers then put them in a separate FILE to reduce storage in the primary data file.
2. The scripting import routine is roughly..

Delete all records in all tables in the NEW file
Open the OLD file
Find all records in all table in the OLD file (run a script in the OLD file)
In the NEW file Import all records from the OLD file to the NEW file
Update the next serial number in the NEW file
Perform any data "fixes" if there are fields that have changed the way they behave. For example, auto-entries that have changed content.

The above assumes..

The OLD file is based on a previous incarnation of the NEW file
The OLD file already has a script to find all records in all tables (it will do if it existed in the PREVIOUS NEW file)
Both files should have a set or "root" layouts and "root" table occurrences for each table
The OLD file must be specifically named
The imports DO NOT update serials and auto enters
Import by MATCHING NAMES
  • 0
Ideal Data - Coherent systems for a chaotic world
I'm available for hire, e-mail me

#5 comment  consultant

comment
  • Members
  • 24,274 posts
  • Time Online: 334d 37m 3s

Posted 26 June 2011 - 02:17 AM

Open the OLD file
Find all records in all table in the OLD file (run a script in the OLD file)
...
The OLD file already has a script to find all records in all tables


Why not simply keep the old file closed?
  • 0

#6 IdealData  IdealData

IdealData
  • Members
  • 2,613 posts
  • FM Application:12 Advance
  • Platform:Mac OS X Snow Leopard
  • Time Online: 8d 19h 45m 46s

Posted 26 June 2011 - 06:28 AM

Why not simply keep the old file closed?


Yes it's not necessary. I actually meant to say:

Run a script in the NEW file which will open the OLD file, and not as a separate procedure as it would appear.

Still, superfluous to requirement.
  • 0
Ideal Data - Coherent systems for a chaotic world
I'm available for hire, e-mail me




FMForum Advertisers