1 of 1 people found this helpful
A> Your last suggestion is the best one. Import data into the new solution.
B> You can however have one file that has your data and use another file(s) work work with the data that would keep you from having import data into your updated file or at lest minimize how much needs to be imported. Especially if it needs to be online 24/7.
1- Is it possible to do development work directly in the live database? i.e. can I add and delete tables, fields, layouts, etc. while users are actually using the database? Obviously I would not be working in the same tables or areas that users are currently using. This seems risky of course, but depending on what other choices there are, it may be at least one way to continue working without bringing down the database.
> While it may be possible to work on it while others are using it, you risk losing the changes they are making.
2- Or, is there a way to merge solutions together? Can I work on a copy of the structure and then somehow merge it with the live solution?
> I don’t have FM 14 just FM 13 Advanced and while you can import tables and scripts (it will break scripts if you have changed a field or table name and not give you a clue what field it was) I have not found a way to import layouts, just have to make new layout and copy and paste.
> Given the speed of importing data, unless you have an extremely large amount of data you shouldn’t be off line more that a few minutes at most. To be sure you have all current data in your updated solution. You need to close the current file so no records can be changed, rename/move to keep others from opening while importing current data to updated solution, rename current FM solution with date in name as a backup. Rename new solution to proper name or save a copy in proper location with the proper name.
3- Or, is the only way to do this is to export/import data into the new solution?
>Given Filemaker's ability to import data directly from an existing FM db, I would avoid exporting data as it makes for one more step for something to go wrong but, if you have an export/import routine for data backup use it. Also, you need to make sure you haven’t got duplicate information.
Use a clone copy when moving to a new solution. I would write a hidden script to do the importing to your working copy of the file.
However, exporting data for backup of it is a good idea.
My guess is "Best" practice would be to proceed with the Separation Model like 4th dimension.
All the same, I've been supporting and building here for the past 5 years on a live dbase with 50 users...it fits what needs to get done.
When working on a specific table, I put warnings on the layouts of potentially affected areas of the times I will be "messing about"...and if I'm diving really deep I'll put an "Out to lunch" tag on the layout letting people know when to try back...then set the fields not enterable in browse mode while I'm working.
This works for 1-2 hour periods and avoids lost data.
If I have to do something really serious, we will pull it off the server and import over to the new build...but that has only happened once. All the rest could be built live, simply by being quite careful with building the "New" stuff first, then warning people...then doing all the interconnects last.