Are the relationships to tables in the same file or tables in a different file? "Run with full access" only applies to the current file and does not enable the script to access restricted data in other files.
hmmmm... good question. the file is built upon the data separation model. but even the users with restricted access to certain invoices have full access to the fields in a global temp field table that i am attempting to access (i am not trying to view or manipulate any restricted fields). however these temp fields are specified in the script using a relationship from invoices to the global temp table with the "x" operator (there is only one record in the global temp table). so it seems like what is happening is that if the user is sitting on a restricted invoice when they launch the script, the relationship will not work (i get an empty value if i look at it with the data viewer during debugging... whereas it works fine if they are sitting on a permitted invoice). it is not that difficult to work around, i can simply go to a different layout based on the global temp fields to which everyone has complete access, get what i need, and come back again, but it was not what i would have expected since no restricted data is being compromised. am i correct in assuming that this is what is actually happening or is there possibly some other reason the relationship is not working (it works fine, of course, with full access privileges)? thanks!
It's hard to know with out examining your file, but I suspect that the record level access restrictions do not evaluate to "true" for the related temp table when the current record is restricted. If so, your system is performing as it was designed to work--just not as you want it to work.
that sems to be my luck!
And am I correct that you have access restrictions set on the tables in the data file and not just on the table occurrences defined in the interface file?
If you do not set record level access restrictions in your data file--but instead set them in the interface file, I would think that your run with full access privileges script would work.
you are correct. user accounts and the associated privilege sets are stored in the data file. you have already exceeded the limits of my knowledge about accounts and privilege sets. i didn't know you could control access to fields in the data file from the user interface... if that is what you are saying? how would i do that? when i go to manage>security>privilege sets>data access and design>records, for example, it only lists tables in the user interface.
in trying to figure it out i went to the "file access" tab in security where i have never been before but i became even more confused. it states that "only authorized files can access tables, scripts, and other elements of this file". but in my data file i have not authorized my user interface file and it does access everything that it says i won't be able to. i am clearly not understanding something about this...? help?
Darn! You are correct about the limits to access security. I had made a quick check in one of my multi-file solutions before posting that last response and was fooled by similar table names into thinking that I was seeing a list of table occurrences in the Custom Privileges set up.
I suggest using a global field in the data file to temporarily unlock access to data in a table.
If you had this for a record lock expression:
FieldA = "Fred"
Change it to be:
FieldA = "Fred" OR Globals::gUnlock
Where you define gUnlock as a number field with global storage.
Then your script can unlock access to data in that table with this code:
#Unlock the table
Set Field [Globals::gUnlock ; True ]
#Do your stuff that requires access to the table here
#Lock the table
Set Field [Globals::gUnlock ; False ]
I'm not sure if you really need the commit records step so you can experiment to see if it makes a difference here or not.
ahhhhh... very clever... that will do it! thanks again.
p.s. any idea what the "file access" tab is actually for in security? the explanation in the tab window doesn't seem to make sense.