Skip to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Filemaker 12 Migration: Server side ScriptMaker does not set global fields anymore

Featured Replies

  • Newbies

I migrated from Filemaker 11 Server to 12 recently. I noticed yesterday our statistics, which are updated through a server side script that sets a couple of global fields, were not updating.

 

I tried several things:

- stop the database server, create new records locally and then starting again, reran the script but the global fields were not updated

- created a new script, recreated the task, but this worked without issues in FM 11 so no luck there

- google google google led me to no known issues or behavioral changes with global fields in FM 12

 

Running 12.0v4 server and client...

 

Anyone has any ideas?

Solved by raveadmin

Go to solution

FM 12 and FM 11 handle globals being set by the server differently. You'll want a table to keep track your log in regular, non-global fields.

  • Author
  • Newbies

Thanks David. Can you elaborate a bit ? Is this documented somewhere?

I don't know if this change has been documented, but after seeing it floating around the forums, I tested it on my own server and it's true.

 

When you open a file, the global fields have the value that was stored the last time the file was closed when that file was not being hosted. Global fields set by a server side script don't persist beyond that individual server session. They won't be accessible to the server if you run another scheduled scripts or to client users.

I don't know if this change has been documented, but after seeing it floating around the forums, I tested it on my own server and it's true.

 

When you open a file, the global fields have the value that was stored the last time the file was closed when that file was not being hosted. Global fields set by a server side script don't persist beyond that individual server session. They won't be accessible to the server if you run another scheduled scripts or to client users.

 

David,

 

Is this really something that changed in 12?  I thought this is the way globals have always been handled.  I always said "Your globals are yours and others can't see them".

  • 1 month later...

Jerry, your globals are yours as you say, but when a file is hosted, the initial values of globals will not necessarily be empty, but rather will be whatever they were last set while in single-user mode. That hasn't changed.

 

Now I can't remember how far back this goes, but it was discovered once we got the ability to run server-side scripts that when a server-side script set a global, that value would persist -- as though the file had been un-hosted, the global set in single-user mode, and the file re-hosted.

 

Apparently this is no longer true in 12. I did not know that!

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.