Runtime in FM Server

[EllenG]

I looked up the forums and also saw this tutorial:

http://www.vtc.com/products/FileMakerServer11/ConfiguringFileMakerServerPart1/92903, but need specific answers/verification on serving up runtime files.

As I understand it, runtime FILES, but not the APPLICATION, can be opened on an FM server, as long as there is a copy of FMPro on each client.

Here are my questions:

Will FMServer 11 open runtime files created in FM10?

My application has multiple files that interact with scripting, etc. using the separation model (data files and format files are separate.) I also have a few plug-ins in the extensions folder. What needs to be on the server and how do the files "interact"? For example, the "main" file in the application is the Herd.AE5 file. If this file is open from the server, will all the relationships to the other files and the scripts be accessible by the server (act like they do in the runtime application?)

Does this approach allow for "true" multi-user access on each licensed node (including updates from "concurrent" nodes?) Is record-level blocking "built in" to the model to prevent updates to the same record by concurrent users; while allowing simultaneous FILE updates (to different records?)

Is there a way to download and test the server option before purchasing the server & client licenses?

Besides the tutorial at VTC, is there any source of documentation that describes this in detail and what has to be done to make the application work on the server?

Is there any other issues that may impact processing?

Thanks for the help.

[Vaughan]

FMS 11 will open FMP 10 runtime files.

Put all of the solution files on the FMS and the solution should just work. It becomes more complex (and fragile) if you want some files hosted and some local.

Regarding multi-user access, FMP will manage the record locking etc by itself.

How ever it is possible to create processes that are not suitable for multi-user: these are typically processes that flag records.

For example, a process might run through a set of records and set a flag (for printing, say) then find these records, print them, then un-set the flag. This works fine in single user but when more than one user is doing it simultaneously the process will break down.

The safe method is to set the record ids into a global field instead of marking each record individually. Global fields are specific to each user so each user can have their own values without affecting the other users.

[Steven H. Blackwell]

The essential answer to all these questions is that once the data files are on FileMaker Server and are then accessed by copies of FileMaker Pro, they then behave as would any other hosted solution.

They must take into account all the rules and caveats of multi-user solutions. Plugins generally will go on the client, not on the server.

Versions 10 and 11 can work interchangeably, taking into account that newer features won't work on older versions.

HTH

Steven

[EllenG]

Thanks for the info. I do have print routines that flag records; I will look into that.

My application was always intended as single-user, although I have clients who run my application in a shared network and that works fine (opening as single-user.) I did not expect any of my clients to incur the expense of a server and node licenses that far exceed the cost of my application; but I do have a client who wants multi-user capability for all users and is willing to incur that expense.

Your response seems to indicate that global fields can be different for each user. This is important, as I set global fields when a record is selected and then use those in many ways, including related file lookups. So, are all global fields stored and processed separately by user? If not, this could be a major problem if a global field is reset by another user.

I probably have other processes that may also be a problem?? Guess they will ahve to download a trial version of the server and see if it will meet their needs!!

[Vaughan]

Your response seems to indicate that global fields can be different for each user. This is important, as I set global fields when a record is selected and then use those in many ways, including related file lookups. So, are all global fields stored and processed separately by user? If not, this could be a major problem if a global field is reset by another user.

In multi-user, global fields have "special" powers here on Earth:

1) The initial value a global field takes is whatever was in the field when it was last closed in single-user mode.

2) Each user can change the value of the global field independently to all other users.

This means that setting the initial value of a global field can be tricky, as can changing it. Most developers set global field values in a startup script to ensure that the value is correct. (Keep in mind that this makes the solution dependent on the startup script running and setting those values.)

Regarding other processes: if they rely on the assumption that nobody else is editing records at the same time (such as a flag field) then it won't work in multi-user.