Modifying solution on FMSA?

[jjfcpa]

We have a solution running in the office on FMSA. There will probably be many changes to the solution over the next few months and I'm just wondering what is the best way to handle a solution that is being modified often.

Especially since we will be entering data into the db regularly.

Do we close the solution on server, copy it off, modify it, then re-load it onto the server or is there an easier way?

Such as, close it and modify on the server, then re-open?

[bcooney]

If you need to modify while people are entering data, then you can't really close it, can you?

If you copy off a backup and work on that, you'll need to use Import to move all the data into the new structure.

We work live often (ok, there I've said it). We run backups often! However, we've fallen victim to record lock and table lock issues. In working live, you will experience New Record and Set Field failing when you least expect it.

There is also the use of the Separation Model...

[Fenton]

This is a very serious business, working on live files in a hosted solution. You can make a simple change, to something like a field definition, click the OK button, and helplessly watch the whole thing come crashing down, with damage to the files; then all the people of the company are out of work while you Recover the file and try and get even a damaged version back online.

On the other hand, I will also confess, I sometimes work on live files, when there is no alternative, the solution has a long history of stability, and no one, or almost no one is actively using it. These are my recommendations:

1. Separation model, an Interface and Data file. Most business logic, almost all scripts, and all layouts are in the Interface file. More than 90% of development refinements are in the Interface table (once the main structure is done).

The Interface file has only such tables as Globals and Constants (fixed text, graphics in container fields, etc.). This (these) tables have only 1 record. It does not need to be Imported. A new one can be slapped into place at almost any time. The only real problem is keeping Accounts/passwords synched in both.

2. A fully automated script, in the Date file, to Import all data tables into a clean clone; a script which is updated regularly to include new fields added. It should also update the "next serial number"* in every relevant table. It must be 100% accurate and reliable. *I use UIDs in small tables to avoid having to do this for everything; but regular serial IDs for anyhere I'd want to see the data.

You need both of these things, as they compliment each other. Live work can be done on the Interface file, scripts and layouts. If a field is needed, then you must add it to the Data file. Best practice is not to do this while the files are hosted. It is dangerous. So stay late or come early. Stop the files, add fields and relationships you may need, to either file (the Interface file has lots of relationships also).

As I said earlier, an offline copy of the Interface file can replace the real one at any time the files are stopped. This gives you a chance to test things during development. Then the next day you can continue, on the live file, refining scripts and layout changes using the new fields and relationships.

All extensive development, especially that involving many new fields and layouts should be done on an offline copy of the files. Then, depending on the complexity and amount of work, you can either copy/paste changes into the real files when they are stopped**, or run the Import/Update into a clone of the development copy.

Scripts and layouts can be copied into live files, if time is short. If there were extensive changes however, to fields and relationships, then you must run your Import/Update into a clean clone of your development files. Unless you have tons of data this does not take all that long on a fast machine. Usually less time than trying to redo it on a down copy of the live files.

** If you copy/paste just a few fields from a development copy of the Data file into the live file, in order to avoid the whole Import/Update operation, the Field IDs MUST line up, start at the same ID and be in the same order. Every new field gets a unique sequential ID. Once they become out of order between a live and offline Data file it is a PITA to get them back in sync again.There is a method to check them first. But problems can generally be avoided by being methodical, and NEVER deleting fields. Just mark obsolete ones, and reuse them later.

P.S. Never ever use a file which has ever crashed (to your knowledge) as a development file. Consider it a "golden master" and treat it with respect. There is no way to undo damage to a file.

Edited November 12, 2010 by Guest

[Steven H. Blackwell]

Do we close the solution on server, copy it off, modify it, then re-load it onto the server or is there an easier way?

Pay attention to Fenton's excellent answer.

Best process:

1. Separation Model with one or more UI/Logic files.

2. External Server Authentication for Account management.

Steven

[jjfcpa]

Fenton

Thank you for the very detail reply. We are not even close to putting live data on FMSA. We are just getting into the planning stages and I want to make sure we know how to make modifications correctly.

[Steven H. Blackwell]

Your key take-away point here should be [color:red]don't do development work on hosted files, especially if there are users connected.

I'd recommend you read up on The Separation Model™ and External Server Authentication, because these two techniques will address almost all the issues you'd encounter developing on hosted files.

Steven