Try defining the globals in their own table of globals instead of the main table. See if that helps avoid this issue.
Then do I need to point the layout to that table. Because I had a problem attaching a field from a table that was not related.
If you are using the fields solely for the purpose of collecting criteria to be used in scripted finds, there shouldn't be any problem. A field with global storage specified, is accessible from any layout and script in your file.
I made a new table for the new globals. However, the only way I avoided the lock was to enter the global fields on a none existing record. I achieved this in 2 ways.
1) attaching the new globals table to the layout. Or any table that does not have records nor will have records.
2) before allowing the user to enter values in the global field, script does a search that I know will result in a 0 found set. (while this is working, I'm not sure that this is a good way to do it.)
When I used the approach 1), my script had to switch to a layout attached to the table that had the records in which I was searching. Then swiitch back again.
I am doing a couple of other things with global fields which seem to be working. Also when I enter the global field. it doesn't seem to matter to what table the field resides as long as the layout is pointing to a non record or not record holding table.
Any thoughts? Thanks so much for your help!!!!!!
2) sounds like a very creative way to handle this issue. No obvious draw backs to this trick come to mind.
For 1), I routinely open a small floating window with the needed global fields. Clicking a "find" button on this layout then performs a script that closes the small "dialog" and performs the find after using the data in the global fields to set up the find requests.