Changing global field remotely

[macavity]

Hi. Not sure if this is a scripting, network or impossible question...

Is there any way for a user (who is also network administrator) to set the value of a global field on a computer other than her own?

[bcooney]

No. But you can "force" global updates by including their setting in a script that is used often, such as the nav script to the Main Menu layout.

[macavity]

Oh well. Thanks for the answer. Unfortunately adding an update to a script won't help in this case. The field has to be updated irregularly, at the discretion of the administrator.

Are there possibly any settings that could be changed on a remote computer, like user name or account name? Anything that could then be accessed via a calculation?

[Vaughan]

Instead of a global field perhaps a regular field in a preferences table might have been a better choice.

Are there possibly any settings that could be changed on a remote computer, like user name or account name? Anything that could then be accessed via a calculation?

It might be time to explain what you're trying to do.

[macavity]

The explanation is banal but here goes:

Two people share the same computer, but their hours are irregular. To avoid personal jealousies, the "admin" is worried about assigning one or the other name as the default user, forcing the other to change it. Silly, but there it is. It would be good if she could change the name whenever one or the other sat down at the computer - without their noticing.

Obviously the name has to be accessible in very many tables, so I was hoping to be able to use a global field. If it can't be done, I realise an alternative would be an "x-field" relationship between the tables and a one-record table with a normal text field. I was just hoping...

[comment]

I am afraid I am even more confused. Do both users login under the same account? If so, why? Wouldn't it be simpler (and more secure) to assign each their own account and password, and require them to login properly? What happens if the admin is not there "whenever one or the other sat down at the computer"?

I was hoping to be able to use a global field. If it can't be done, I realise an alternative would be an "x-field" relationship between the tables and a one-record table with a normal text field.

No, the alternative would be to set a global field (or a global $$variable) to the value stored in preferences, as part of the startup script. But it shouldn't be necessary when people login individually, since the account name is always accessible.

[macavity]

Thanks, but unfortunately I can't do it that way. They don't log in separately, they relieve each other at random times and just carry on the job. Logging in would cost time and they don't want to. These aren't sensitive data.

There is a simple way for them to change the name themselves, but the idea is to avoid their having to do it whenever possible.

I realise this is a silly situation, but I've been asked to do something along these lines. I was curious to know whether it would be possible. I'll say it isn't.

[comment]

These aren't sensitive data.

Then what is the name being used for?

logging in would cost time

Not necessarily - they could keep the file open and "log out" by relogin to a dummy account with no privileges.

In any case, the admin cannot make this change alone, without some action being taken at the local workstation when the users change.

[macavity]

Thank you comment for taking the time to answer.

They need the name because they have to know who entered what (eg. who created a new contact, who talked to a client and made the notes).

The dummy log-in sounds like a good way to go. I'll see if I can convince them to accept it.

[comment]

they have to know who entered what

I'd call that "sensitive". It's the same thing as changing cashiers at the supermarket. Assuming they don't want to be blamed for the other person's mistakes, they should be only too happy to cooperate.

[bcooney]

Just wanted to point out that the user name in Preferences is not the Account Name.