Development database?

[aweaver]

I'm a newbie here and pretty new to FileMaker. I come from an Oracle Financials background. I will have to be making changes to a few FM databases (FM 11, FM Server) and want to know the best way to approach this. I'm used to working in an environment where there are dev, test(qa), and production instances. Can someone tell me what the usual approach is - I want to make changes in my own "sandbox" database and then copy them to a test database where the users can test and signoff and then migrate the changes to production. Thanks!

[Vaughan]

In my experience, the "usual approach" with FMP development is to work on the live production system.

The Emperor has no clothes!

Basically you can do whatever you want. If you want a development and production system then set them up. You have, however, just doubled the development time and cost for the client.

FileMaker databases don't have separation of data and interface, so migrating changes to production means importing the production data into the new system and loading the new file onto the server. (This loading of data may be complex if the data structure has changed significantly between version.)

There is a "separation method" which you should look into, which is a development practice that provides some separation of data and interface. It is not a silver bullet for the problem, as it creates significant development overhead. It is most useful when the changes are to the interface not the data structure, which in my experience, is infrequent especially during the early stages of development.

[aweaver]

In my experience, the "usual approach" with FMP development is to work on the live production system.

The Emperor has no clothes!

Basically you can do whatever you want. If you want a development and production system then set them up. You have, however, just doubled the development time and cost for the client.

FileMaker databases don't have separation of data and interface, so migrating changes to production means importing the production data into the new system and loading the new file onto the server. (This loading of data may be complex if the data structure has changed significantly between version.)

There is a "separation method" which you should look into, which is a development practice that provides some separation of data and interface. It is not a silver bullet for the problem, as it creates significant development overhead. It is most useful when the changes are to the interface not the data structure, which in my experience, is infrequent especially during the early stages of development.

Thanks for the response, Vaughn. But can you explain further how one "sets up" a test database. Is it as simple as copying the database? I'm hesistant to do this since I read that no user can be on the system while this is happening and that there could be some issues with copying databases on FM Server. Any suggestions would be really appreciated!

[David McQueen]

You say that the databases are already on server. Just take one of the current backups and voila "Sandbox".

1. Take this over to your local machine.

2. Rename it using a copy of FMP Developer and the developer utilities. Do not just rename the file.

3. Also change the passwords for the various accounts, especially if you are going to do your development work from the server on the sandbox. You absolutely do not want anyone getting in there as once in, they will not know your sandbox from the real deal and could start trying to enter data.

4. Decide whether you are going to run the sandbox locally or on the server. It will probably be on the server to test all functions and for various safety reasons. I end up working locally on a sandbox much of the time as my clients are all over the place and either WAN development is really slow or they are not equipped for WAN access.

5. When it comes time to implement in the real files, you will have the capacity to have both open at the same time on your machine and do some copy and paste between them to eliminate transcription errors.

HTH

Dave