Jump to content
Salesforce and other SMB Solutions are coming soon. ×

'Globality' of script variables


Norma_Snockurs
 Share

Recommended Posts

Does anyone know if a global script variable as featured in FM =>8.0 enjoys the same 'globalness' as a regular global field i.e. is only global on a per user basis but it's initial value if set whilst unshared is truly global? Behavioural differences?

Link to comment
Share on other sites

With global and script variables, the scope is limited to the file they are defined in. Other than that, they have the same kind of session-specific behavior as global fields--except of course, that they don't default with the same values as they had in single-user mode.

Link to comment
Share on other sites

I had a hunch that might be the case. I guess I was hoping that FileMaker might have eventually got around to providing us with a truly global variable option. I guess I'll just have to stick to defining a globals table and setting field values through the creation of a sole one-off cartesian-related record (sigh) which seems clumsy.

 

The irony of having to use a non-global field as a way of creating a truly multi-user global field is not lost on me.

 

Thanks Ender.

Link to comment
Share on other sites

I can think of uses.

 

Let's say you're running a multi-user retail sales db in a locale where periodically, to stimulate business, the politicians suspend the sales tax, which under non-suspended contions is calculated per the client insofar as the tax rate depends on the client's billing city and state.

 

Be nice if the chief financial officer or the corporate accountant or someone else authorized in financial could set a new kind of variable or global, that would be accessible to all users in the system, that would be referenced in scripts or calcs and which meant, in essence, "Tax rate is 0% because taxes are suspended".

 

To do that now, you'd either have to create a single-record table and use a local field (as Norma_Snockurs describes) or you'd have to do a Replace on a switchfield in each client record, telling that client record that the tax rate is 0 because switchfield is "NoTaxPeriod" or some variant, or you'd have to have all taxes be applied via a script which you'd edit and then re-edit back when the tax-free week was over.

Link to comment
Share on other sites

What are you using such shared values for?

 

A call log database hooked up to a PABX phone system's serial port (credit to Troi Serial plugin). New records are created via a global timestamp to individual record timestamp relationship.

 

I also have a couple of users in a satellite office of the company who's calls also get entered in the same log using a different method (Phone Valet) but this still requires reference to the same global timestamp in order to permit calls co-incidentally ended on the same timestamp at different locations to simultaneously create new records.

 

There are are three clients, a server, an intranet & internet involved. All are networked time synced.

 

It's actually a little more complex than that & I did experiment with other ways to do it (too much scripting) before hitting on this as the fastest & most reliable (100% so far) but, hey, I try to keep my posts reasonably short. Leaves more time for developing & earning.

smiley-wink

 

If you think about it there are probably a fair few scenarios where a true multi-user global would prove useful. Maybe this post should have been in FileMaker Pro Wishlist.

Link to comment
Share on other sites

Hey Norma, Guess I'll have to take your word for it, as I'm not seeing it from your description.

 

Ho Hunter, I wouldn't have believed it if you didn't give the link. Maybe you guys should just lower your taxes a bit and forget the free week. Give you poor database developers a break. We're up to about 7% here, but with every sports team that comes holding out their hand, the tax goes up a bit.

Link to comment
Share on other sites

OK here's another then.

 

I have a text field with a return seperated list of all users logged into any served DB file at any particular moment (no, it wasn't my idea). A users name is entered via a script line in a file's open script and removed by a similar process when all open files are closed on a particular client.

 

This will only work simply if written to a single record's field. I can't see how a regular global field would work in this context though I'm always open to ideas.

smiley-smile

Link to comment
Share on other sites

Any process that has all your users editing one record is going to be a problem. I don't see how system-wide variables would get around the inherent record-locking type of issue here.

 

In any case, there are some limitations to the effectiveness of trying to track which files are open based on logins and logouts. There are several ways the process can fail and not properly add the login info or clear the logout info. However, I do think the record locking issues could be avoided.

 

In this example, you could instead use a table where each record is one user's open file. Then delete those records as the files are closed. Those records could then be viewed in a portal of users that have the specified file open.

Link to comment
Share on other sites

Well I agree that trying to get multiple users to write to a single record is a daft idea as it's theoretically almost bound to fall foul of a record being locked out to all other users whilst one particular user edits it. Having said that I can't get my particular use to fail yet (but I'm not claiming it won't smiley-laughing). And you can rest assured that I was dumb enough to have not thought of that at the time.

 

Perhaps as the process is only triggered by a script on DB open or close, I only have a handful of users and the DB's in question are served by FM Server it may never happen. I certainly would like to know if it's by pure luck or because of the way FM Server threads or queues file opening/closing processes or some other voodoo that it isn't happening.

 

I think your suggested alternative method makes sense anyhow as it certainly doesn't rely on luck.

Link to comment
Share on other sites

 Share



×
×
  • Create New...

Important Information

Terms of Use