inconsistent effects of privilege sets

[tomp]

I have 2 runtime solutions. One runs in the background and is started with a 'send event' from the other. All files in both solutions have the same user names, log in name, privileges, and privilege sets. The log in name is NOT a full access account.

The run times were created in the same account. Everything runs as desired in this account.

When run in another account, the background solution runs as expected when started by clicking the application icon in the Finder. However, when started from the 'send event' script step in the foreground solution, the following message(s) occur whenever a change to table data is attempted:

'Your access privileges do not allow you to add or modify records in the target table' (an import was attempted).

'This action cannot be performed because this file is not modifiable' (a set field was attempted).

It appears that no actions on the data can be completed.

Using a 'Get(accountname)' I have verified that the log in user is in fact the account that is active. The privilege set for this user has for 'records' - 'create, edit, and delete in all tables'.

Any insight into why the privilege set is applied correctly in the creation account and inconsistently in another account even when the privilege set for the user should allow table modifications??

TIA

[Vaughan]

Is the file locked (read only) at the OS level?

[Reed]

Are you trying to modify the same file with two different run time applications at the same time?

[tomp]

I do not believe the file is locked since it can be modified when launched from the finder in any account. The 'cant modify' messages occur only when launched by 'send event' from an account other than the one it was created in.

The 'background' runtime does not access nor try to modify any data in any other open database. It imports data from closed files for use in processing.

[Reed]

I do not believe the file is locked since it can be modified when launched from the finder in any account. The 'cant modify' messages occur only when launched by 'send event' from an account other than the one it was created in.

Are you talking about OS X user accounts or FMP accounts? If it's OS X accounts, are you switching accounts using fast user switching? (two accounts logged in at once) This could possibly cause file locking problems.

Have you tried creating accounts for the runtime that have full access and setting them as the default account? Does the problem still occur?

[tomp]

The 'cant modify' problem was due to OSX file permissions. When installing the runtimes on the OSX account that created them, everything was ok.

When installing the runtimes on another OSX account, the 'you can' for the background runtime data file was 'Read only'. That apparently wasn't an issue when the runtime was launched from the finder, but was when launched from 'send event'. When the 'you can' permissions were changed to Read & Write, the 'cant modify' messages disappeared.....

BUT I've encountered yet another roadblock (this has been quite a journey). This may be more a question on 'import & export' but I'll post it here since that's where I am.

The first thing the background runtime does is import parameters from the foreground runtime (using just-backed up copy files - not the active foreground files). The import option is to replace current data.

When run on the OSX account that created the runtimes, the import yields the correct results. When run on another OSX account, the import seems to do nothing. Error capture around the import says there was no problem. The log-ins are both full access accounts.

Is there something about 'import'ing from another runtime in an OSX account different from the one the runtime was created in that I need to know about??