Turns out the following did NOT solve issue.
Update, the following worked:
NEW calculation field: TASK_TEST (task_created_by=$$user_id)
VIEW TASK records when
Any thoughts why the global variablewouldnot work? It works in nearly 20 other instances.
Global fields and variables do behave differently in shared/networked environments than single user, but I don't see anything in your posts that suggests this "difference" might be a factor--especially given that the calculation field refers to the same global variable.
Is the new calculation field a stored or unstored calculation? (looking for differences that might explain the issue.)
Well, it appears I can't recreate my success. How is that for nailing tihs down?
How do you assign a value to $$User_id ?
A sert variable command in the "open" script I have assigned to run upon login. I have a USERS table that has the pre-assigned User_ID and User_group based on its related Account Name.
I used the following command:
set variable($$user_id; Users::user_id)
And that's how I expected you to do this and no, I don't know why it's not working for you. :(
Well, at least I know I've not gone in the wrong direction.
I wonder if I tried to unhost and tried to rehost it. In addition I've considered creating a new task table to see if that solves it.
I doubt that taking the file up and down off the server will solve anything:
Things I can't test from here:
Can't check to see if any other code might modify the value of $$user_id. (I'd use the debugger and data viewer to monitor the value while scripts execute and search a database design report for all instances of $$User_id to make sure there isn't something I've over looked.)
Can't confirm that value in variable exactly matches the value in the task_created_by field (no spaces or other invisible characters.)
Can't replace global variable with global field and see if that works any differently. (It shouldn't as far as I know...)
I've done all of those, but I noticed that I have been using FIELD and VARIABLE interchangeably in my posts :-/
It is a global FIELD I have been using to secure the records.
Setting a global variable would change as new users log on making all records inaccessible except for the last person to login. The global field allows the personalization for the user.
Thanks for the help, having a dialogue at this point in the day was helpful. I'm going to let is sit overnight and see if I have any brilliant ideas.
Each user gets their own set of global variables and changes made by one user to a variable won't affect the value for another user as is also the case for global fields. In this situation, I see no reason why a global variable would function any differently than a global field.
$$User_ID is the typical labeling format for a global field. To avoid confusion, I'd rename global fields to not have the $$ at the beginning. I use a lower case g for these in my solutions for easy identification: gUser_ID instead of $$User_ID.
I really should not have skipped lunch, and I would like to state that I am sober. I've been swapping nomenclatures something terrible as I have been using variables not fields. This is embarrassing to admit right below my declaration above. I agree with your variable and field naming conventions.
Regarding my problem, I solved it with get(account name)=task_created_by; nevertheless, I'm going to perseverate on this until I can determine why it wouldn't work with this table. It works, but I fear this similar problems creeping into other accessibility parameters.
Thank you kindly for your time.