Start-up script doesn't always run

[brian rich]

We have a large number of hosted (legacy) databases running on FMP11 Server Advanced. Most of the time, our users will open these databases directly as they need them. Under these circumstances any start-up script that is set in the preferences will run automatically. 

 

However on occasions databases are opened indirectly as a result of a relationship becoming active or when a remote script in an unopened database is called from a script running in the current database.  Under those circumstances, it appears that the start-up script does not run. Databases opened in this way appear in the window > show window item on the menu bar, so users can - and do - select them to bring them to the front - but the start-up script doesn't run when this happens.

 

I'd like to make sure that certain global fields and variables are always present with specified initial values when a user is using a particular database but if I can't guarantee that the startup script runs, I'm not sure how else to do this.

 

Thanks

 

Brian

[IdealData]

You need to get the global fields 'embedded' into the databases. You can only do this by using FMPro (or Adv) as the host, set the globals, and close the file. Then re-upload to the server.

 

The key to this is that the globals are saved when the host closes the file, but this does not apply when FMServer is the host.

 

Global $$variables cannot be preset in this way and must be initialised via scripting.

 

As another alternative you could have each file open the related files from their own start up script.

 

Wouldn't a menu file be a better option rather than users manually selecting a file from the host dialog box? This way you can control the scripting much better.

[brian rich]

The values we'd like to have in some of the globals have different values for different accounts, so depending on what values are in the hosted file won't work.

 

We do have a menu system - the problem is that the users have discovered that they can save themselves a couple of clicks by selecting a window instead of going via the menu. 

 

WIth new databases, we make sure that the appropriate related files are opened correctly by forcing them to run a start-up script when we open the main database.  It's the legacy databases which don't do this where we have this issue.

 

Just need to find a dependable way of getting that start-up script to run...

 

Thanks

 

Brian

[IdealData]

Introduce a dummy 'Welcome' layout on the legacy files which is the startup layout, with an 'Enter' button that will run the opening script.

 

Or, use custom menus to remove the Window menu options.

[dansmith65]

A trick I've used in this situation is to add a layout script trigger to the startup layout. If you use both this and a standard "run script on file open" script, then the script will run twice.

[Vaughan]

The startup script runs whenever the first window of the file is opened: as you have discovered, this could be never. This is not a bug: design a solution so it will work without a script running to prepare things.

 

Values that need to be persistent should be in a single-record preferences table -- look it up, it's not hard to make. DO NOT use global fields for persistent values.