Setting file option can be force all users.
Do you want another layout for while the file is not hosted (aka developing phase) ?
If the file is served on server then the only way you should access is thru the server.
If you leverage the On First Window Open trigger or set the on file open layout in options you'll be fine.
Seems like more details of exactly what you want to do are needed.
I don't think you can do what you're trying to do.
It sounds like you want to issue a command and all users will be taken away from the work they're doing and go to a layout. Not just on startup, but at some arbitrary time.
You can't really do that. There's no way for server, or for a client, to affect other clients that way. You could manipulate users using some triggering event like a layout change or record load. Even an InstallOnTimer script (which tend to be really annoying).
The real question though, is WHY do you want to do this? What goal are you trying to accomplish that would want filemaker to do this?
Thank you , all.
I think you got my question.
Why i need to do this?
>> there is a time i want to "update" the data for a certain table, and sometimes there's a user(s) are using the record in that table which will stop the "update" ( the way for update is to delete all records and import new records in that table).
>> so , I want to kick all user out from that table , which is get them to a different layout.
Hope it makes sense.
As a general principle, this is a bad idea. Let me repeat: Bad Idea. No, let me repeat again: Really Bad Idea. (Hope I wasn't unclear.)
If a user has a record locked, it's because the user has begun editing it. Even if it were possible to force the user out of the record (which it isn't), doing so would cancel the user's edits - meaning all his changes would be lost. You'd wind up with, at the very least, some really angry users, or worse, lost business data and potentially damaged data integrity.
Now, in your particular case, you may think that the data integrity concerns don't apply, since you're apparently deleting all records in the table anyway. But if that's the case, how are the users locking the records? If this is a domain table - something that you're updating with a batch job - they shouldn't have the ability to edit it. You can lock the table against edits in the Security dialog, which would fix your problem.
If for some reason they do need to edit it, and you still need to blow the records away with a batch script (I really can't imagine such a scenario off the top of my head, but it might exist), what you should do is test for error code 301 in your script and cancel the action if it's detected. You can either record the record ID of the record that threw the error and try again later, or set a loop with a pause to try a few times to see if the user finishes the edits.
Thanks for your reply.
I think you got me! Yes, user have view only . how could they lock the record?
>> the reason the record is locked because there's some cases they can access the field but not modify them,
>> one is to do a find matching.
>> and one is when they do exporting, in script use "go to record" or something like it.
Anyway, that's a very good suggestion. we might figure out some way to unlock the record to avoid make things complicated.
By the way, we did succeed by using Install on timer to do this which is mentioned in the post above. (We are not sure how "annoying" it would be like the post above mentioned.)