Jump 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.

Featured Replies

I am having a hell of a time with global fields in multi-user mode! Just when I think I understand how they work... confused.gif

My custom authentication scheme relies on a global variable in each file (gUserId) to be set to the username from my custom login layout in the main menu file.

I have a file whose only purpose is to store this global username and the current logged-in status. If someone tries to close this file, the entire system is closed. I have all files set to check this value using a constant 1=1 relationship upon opening and then re-sync the global userid. In my menu launcher, I had to explicitly put in Open("Filename") statements, because I needed to make sure the closed and re-opened files went through the startup script.

This system seemed near foolproof, yet the global userid field is still switching to the value of other logged in users. This is driving me crazy!

Each file uses this global userid field in the left side of a relationship back to a staff file so that it can lookup privileges. I must still be missing something with globals in multiuser mode.

Does anyone see anything from what I stated above that may be inherently wrong, or possibly a way to trap the problem?

A more detailed description of the files that make up my system can be referenced in this thread:

http://www.fmforums.com/threads/showflat.php?Cat=&Board=UBB19&Number=67129&Forum=All_Forums&Words=9601&Match=Username&Searchpage=0&Limit=25&Old=allposts&Main=67129&Search=true#Post67129

Globals are definitely private to each user. If it's setting the value to another user's ID, then I'd double check that you truly have defined it as a global field and not a regular text or number field.

One other possibility is that you are somehow closing and then reopening the file that contains the global. If this is the case, then the value may be re-initializing to the last saved value on the host.

What you are describing should work if you are using FM Server, but if you are just sharing with multi-user, then the global will be shared amongst all users. If they are served however, I believe each individual has their own copy.

Please correct me if I'm wrong, but this is what I thought the behavior was for each scheme.

but if you are just sharing with multi-user, then the global will be shared amongst all users

If you're sharing the database from another client, the serving client can change the default values stored in the globals. So if you set the globals on the server, then open the client, the client will have the same values (initially).

To get around this problem, create a script that clears (or sets) the global fields every time the file is started up. You can set this script to run every time the file is opened.

  • Author

I am using FM Server.

Also, each file is set to set the global from the reference file that is storing the proper value of gUserId. i.e., each file is set to

Set Field("gUserId", "LoginConstant::gUserId")

I know this reference file does not close because it is set to run a script that exits the entire system on closing.

Create an account or sign in to comment

Important Information

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

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.