Global fields are completely relative to the user session: each user gets their own value. The PSoS is basically another user session. So most likely the PSoS script was indeed incrementing the global up to 12, but that could not possibly affect any other user on the database.
You might have to reconsider using a global field, replacing it with a normally stored field instead.
That is how I was reading it too. The problem is I have up to 4 users connected to this database on the server and I want a script to refer to this number each time a user presses a button.
There must be another way around this, but I can't think how
What does this number represent? Are you counting users? If so, try the Get( UserCount ) function.
Generally it's better to describe the problem you're trying to solve, rather than describe the solution that almost-but-not-quite works.
So far, I see no reason to perform this script on the server. But since it won't work as described either way, you'll need to use a non-global field for your counter. You might need a record in a related record linked by a Cartesian join to get a value that is globally accessible but shared by all users.
Only problem is that I have been reading that this needs to be done by the server.
Can you explain this a bit further? This is crucial in your story and points to an assumption that is probably not correct.
Yes. So the reason I went with the global field was that it is a variable that can be called upon but not necessarily stored against a particular record. Sorry Vaughn it isn't users, but transactions per batch of which there can be only 12 and they have to be unique. So if any of the 4 users creates a transaction, then they give it a number, however the number has to be between 1 and 12. It has to be unique per transaction and between 1 and 12 but over the course of the time it there will obviously be many of the same number in a particular table.
So I think Philmfdjunk is closest, but I am not sure entirely how to set that up. Ultimately I need a counter field between 1 and 12 somewhere that can be reset at 12 and called upon by any of the 4 users at anytime with split second notice to give the next number.
transactions per batch
Would seem the key phrase. You need a table with one record to a batch. That batch record can be used as the context from which the transactions are counted. If only one user is allowed to edit transactions for a given batch at a time, a 12 row portal to transactions becomes a simple way to set a limit at twelve.
And I still see no reason to use a server side script.
So if any of the 4 users creates a transaction, then they give it a number, however the number has to be between 1 and 12.
I don't understand why they need the number but disregarding that:
- global fields or global variables is not the way to go here. Those are unique to the user's session and trying them to force them to be is not a good idea
- what you are describing is similar to a check-out process. Someone who starts a process 'checks out' the next available batch number. The way to do that is to keep the next available # in a table. As a real field, not a global. When the process starts the user tries to open that record. If it fails it means that someone else is checking out a number so the user has to loop and wait. Once they can open the record they keep it open, grab the number, increment the number and write it back to the record and then commit the record.
1 of 1 people found this helpful
It might be simplest to create 12 transaction records by script every time someone starts a new batch and not allow users to create or delete them. Users would update one of the existing set of 12 records as needed. A "clean up" script could remove any unused transactions if the batch ever reaches such "complete " status where more transactions will no longer be needed.
Yes I agree. I was looking at this all wrong. I think a separate table is the way to go with the transaction records is the way to go.
I was thinking about the global fields, but as you say, this is the wrong application for them. I will set up a separate table now.