Sorry... I meant "commit record", not "lock record".
That's the confusing way that globals work - at kleast I assume you mean global fields (fields defined as storage type = global) as opposed to variables defind as $Variable.
Open a file as single-user, set the global field values, and they will stay. Open the file as a guest and you will have your own, session-dependent set of those global fields. They will not be stored on the host - when you close the file and re-open it will have the original values in those fields.
It is really useful to have a complete set of global fields available to each guest session - but it is also very confusing, and has caught out lots of people. You could join the campaign for 'local-global' and global-global' fields, similar in their functioning to $Variables and $$Variables.
My way around it is to have your table (where you store the serial numbers) as a single-record preferences table, with normally-stored fileds and not globals. Make sure you stop everyone, even you, from creating or deleting records in it after the first one. You may also need to create explicit relationships to it now, as calculations that worked OK when other tables were only picking up the global value may not now work.
Yes I meant global field. That's a GREAT explanation. Thank you. I will try out your suggestion.
I try to RTFM (read the ___ manual) but I have to admit I'm a little stuck finding information on preferences tables. May I trouble you to give me a clue on what a preferences table is?
Thanks very much
I tried to RTFM before I posted to send you the link in the Help File, but I gave up and just posted anyway. You are rading to much into my term 'Preference Table' - "have your table (where you store the serial numbers) as a single-record preferences table".
If the table where you currently store the serial numbers is only used for that purpose, that's fine. If it is used for other things as well (that would need to have more than one record in it) then create a new table. I call such a table 'Preferences' and use it to store info - like your serial numbers - that are 'preference settings' for the whole file.
Create the field SerialNumberNext (if that name is logical), have it as a normally-stored field, and set it to be the one that is updated by your existing scripts.
I would also create (in this new, or the existing, table) another useful utility field. In fact, create it in every table you have, as a matter of course. Call it 'ConstantYes' and make it a calculation, result text, = 'Yes'. Then link from any existing table to your prefences table with that field. It means that every recond in any other table will always match the single record in your 'Preferences' Table, and will be able to set or read the serial number - just the way it does as a global in a single-user set-up.
Thanks again. I added the ConstantYes field to connect the serial number table (what you called the preferences table) with the product information table. There are several tables, each one for a different product with a unique serial number. Do I then create table occurrences of the serial number table to connect with each product table?
Why not have the serial numbers in the one Serial Number Table, called SerialNumberNextProductA, SerialNumberNextProductB, etc?
The table of Product Bs can link to the Serial Number Table the same way as the table of Product Bs, and update their own particular serial number.
On a side topic, then, can I ask if the several tables with different products are largely the same table structure, just with different proeucts listed in them? Or are they each a significantly different structure of table?
This is what I did and everything works fine now though it's not "pretty." I do hope the Filemaker folks make--as you put it--a global global field.
I have one table with serial numbers for all products and made TO's for each different product. The products are water analysis sensors and controllers. Some products are similar and are TO's of one table and some are completely different and have their own tables. There is a lot of testing data that accompanies each product. I am guessing that's what you mean.
If so then "case solved" and I am very grateful for your help. Thanks a million.
Hmmm... it should be pretty. In fact, if all you are doing is tracking a set of serial numbers, then the Serial Number Table should just have one record, with one instance each of the serial number series (plural) that you are tracking. Every table that needs to track a serial number can refer to this directly. So, if you have a table of Water Analysis Sensors that need serial number tracking, then that one table refers to the Serial Number table once. If you have another table of Water Controllers then there's a second table that refers to the simple Serial Number Tracking table, once. I'm slightly confused by you saying 'it's not pretty' - it should in essence look almost exactly like the way you were doing it, with global fields, that worked single-user. The only difference is that the serial number logging fields are not global.
But if you're happy and it's working, that's the main thing!
I believe I am doing exactly what you suggested. What I mean by "not pretty" is that before I had one global table having only one table occurrence. Now I have a TO of the serial number table that is connected to each product table. Plus I have one extra field-"ConstantYes" that is not a big deal but still one more field than I had before. The relationships graphs just got a little more packed. A "global global" table would have been much cleaner.