Server Newbie Question

[soulicious]

We've just purchased FM Server 9 and I'm really excited about our commitment to FileMaker Pro for future development.

My newbie question is: Is it OK to continue development on a database hosted by FM Server while it is "open" on the server and others are using it?

Up to this point all development has been on my local copy of a db, and when new functionality was needed I was the only person in the file making updates. Once I was done, I deployed the solution again to our staff with the new functionality. I'm concerned about data corruption or some kind of conflicts.

For example: staff member 1 is in layout "Main". Staff member 2 is in layout "Other" which has some of the same fields as "Main". I am asked to add a new field to the solution and put it on the "Main" layout while the staff members continue their data entry/runnning scripts/finds etc.

Could this cause problems? What's the "Best Practice" for continuing development while users still access the db? I haven't found an answer explicitly spelled out in any documentation.

Thanks in advance for your help.

Sol

[Vaughan]

Hi Sol.

Most developers do work while the file is on-line. However, the experience of others has shown that if a network outage occurs while fields and relationships are being defined, the file is damaged irreparably. This should be a warning for users of wireless networks. I have never experienced it myself but I'm keenly aware of it's possibility and make frequent backups.

The best practice -- especially for large, mission critical systems -- is to have separate development and production systems. Modifications are made on the development system, then tested, signed-off, and lastly applied to the production system.

[Steven H. Blackwell]

[color:red]Pay attention to Vaughan's comments. They are on target.

Steven

[soulicious]

Great! Thanks for the heads up. I'm setting up my backups right away. Most of the development on existing databases will be minimal additions, so I won't have too large of a window for outages.

New, or more critical development, I'll do on my local system before putting them on the server.

I really appreciate the FileMaker community!

[Sir Boaregard]

I have seen many cases where developing live files can actually corrupt the files. As others have posted, I would never perform any design modifications to a live file.

[victorialine]

I have some questions, and this seems to be the closest topic.

1. So if a file is on a server, and I need to make a small change - you are saying that it is best to NOT make that change on the server?

2. Is there a difference between making a change to a script vs. creating an additional field vs. just putting an existing field on a layout vs altering relationships?

3. If I have already done some of the ''verboten" things, I suppose the thing for me to do is to check to be sure that my db is not already corrupted? If so, can someone point me in the direction of how to check that? I'm sure it has been discussed.

4. It appears that what is being recommended as best practice is:

a. make the changes when no one is modifying the data on the db

b. download the current db

c. make the changes (test, etc)

d. upload new db to server.

Now, all this seems to be a lot to do when just making a small modification - AND I agree that not having a corrupt db is worth the trouble, I'm just wanting to be sure that I have my hands around WHEN I need to do it, and what the correct PROCESS is.

THANKS,

Cin

[Vaughan]

"1. So if a file is on a server, and I need to make a small change - you are saying that it is best to NOT make that change on the server?"

I make changes to live production files all the time on a daily basis. Where I word it's the most efficient method. However I am aware that a network outage while in Define Fields will KILL the file so I minimise the risk. Files are backed up regularly each night and I have a reliable wired network connection, network gear is on UPS etc.

"3. If I have already done some of the ''verboten" things, I suppose the thing for me to do is to check to be sure that my db is not already corrupted?"

How do you know if you're getting the flu? At first you don't feel quite right, then later the serious symptoms appear like high temperature and a runny nose etc. Same with data corruption: you'd know because data might be disappearing and funny things would be happening like ghost scripts that can't be deleted or layouts that crash when viewed.