Server and FmPro installation

[Greg Hains]

Hi.

I have several databases installed on an FMS 11 Advanced on Windows Server 2008 R2 elsewhere on the Internet - ie not here with me.

Developing the database can be slow at times and would like to remote into the server and develop it there. Can Fm11ProAdv be installe and run on the same box as server? The specs say so, but I have found that one or the other tend to play up.

Am I just unlucky or has somebody else also experienced this? If so, and fixed, what do I look out for?

Cheers,

Greg

[Matthew F]

The specs say so, but I have found that one or the other tend to play up.

I'm not sure what you mean. Have you tried it? It shouldn't matter if you access the files using FMPro software which is installed locally on the server or on a remote machine as long as you don't open the data files directly, but instead use the 'Open Remote' dialogue.

...insert usual disclaimer about developing live databases, backups, blah, blah...

[Greg Hains]

Hi mfero.

Thanks for that.

Well, as long as others have done it successfully then I should be able to replicate that success - just needed to check that the "specs" were correct.

Yes, I hear your disclaimer re developing on a live database. Not the best option I know, but am on a really tight timeframe and time zones are not in my favour.

All good on the FmPpro and FMS front so will give it another go.

Cheers,

Greg

[Steven H. Blackwell]

I would [color:red]strongly recommend that you do not run FMP on the server machine at the same time FileMaker Server itself is running.

Steven

[Matthew F]

I'd like to point out again that there are two issues here, both of which are generally frowned upon.

1. Developing a live database, i.e. making design changes to a database that is currently being accessed by users.

2. Running FMPro on a machine running FMServer.

There are a lot of good reasons for not doing either of these activities, but they have different potential problems. Obviously no one would recommend either one. However, doing so will not make your machine blow up, nor will it cause automatically cause software conflicts, data corruption, or other horrific things.

As far as item #2 goes, it seems to me that it is in general bad to run any software on a FMServer machine other than FMServer. This goes for a web browser, email, etc. Particularly bad is anything that might cause the system to lock up and force you to reboot the machine. Active users could lose data or worse. However, FMPro does play nicely with FMServer even if on the same machine. You won't be able to open the actively hosted files, FMServer will (appropriately) lock you out. If you open them using them using the 'open remote...' feature things will behave no differently then if you were on a remote machine. The issues with item #1 would still apply.

As far as item #1 goes, there are potential problems if you are actively changing a database design while other users are accessing it. They will experience unexpected behavior if you change a layout or a field definition while while they are trying to enter data. The system won't blow up, but you will annoy them. I don't know about you, but I often need to debug a script, a calculated field, or relationship before it will work right. Having an unsuspecting user start to access these features before they are ready for prime time could be a problem. I don't see a problem of developing a live database while no other users are connected. You should make sure to have a backup in case you botch something.

[Ted S]

A year or two back I read a post on Filemaker's TechNet where the author said that he routinely developed on a database that was being hosted by FM Server. Now the difference here is that it was not a database being used in production, rather it was a database that was used strictly for development. Basically, there were no users, only developers working concurrently. This fella made a good case for developing is such an environment. Any thoughts on this type of arrangement?

[Wim Decorte]

It works and it is efficient for backups during development.

There is the added risk that during a schema change commit your connection to FMS fails and that has been known to completely trash the file.

So if you have a very stable network connection to the serve you should be ok. But the increased risk remains. You can offset it a bit with a good backup plan.

I wouldn't do it on a wireless connection...

[Ted S]

That's basically how I develop. I'm on a wired LAN, my PC on a UPS, the FM server on a UPS, the network switches are on a UPS, and the entire server room will automatically cut over to a diesel powered generator 30 seconds after a power failure. I get automated backups every few hours. It's a pretty good system and I have been developing like this for many years.

I mention this because it's too simple just to say that developing on a hosted database is asking for trouble. I'd say that developing on a database that is in production with active users CAN indeed be dangerous but there are other factors that should be considered.

[Wim Decorte]

I wouldn't go as far as advocating development on live production files with user's connected! Each time you commit a schema change you will have unforseen consequence if a user happens to touch that bit of schema you're modifying.

One small example: if you commit a layout change and a user is just in the process of going to that layout, his action will fail and he will end up on the very first layout in the list. More than likely a totally different context than your script intended him to be. BIG data integrity risk right there...