the place to look in documentation is in "Triggers" http://doc.4d.com/4Dv16R4/4D/16-R4/Triggers.300-3317281.en.html
quote: • With 4D in local mode, the trigger works with the current selections, current records, table read/write states, record locking operations, etc., of the invoking process. • With 4D Server, only the context of the database of the invoking client process is preserved (locked records and transactional states). 4D Server also (and only) guarantees that the current record of the table of the trigger is correctly positioned. The other elements of the context (current selections for example) are those of the trigger process the language is a bit indirect, but the read write state falls under "other elements". also a must-read: http://doc.4d.com/4Dv16R4/4D/16-R4/4D-Server-Sets-and-Named-Selections.300-3423889.en.html a good use of the shared context is to create a set or named selection without a prefix on the client and pass its name(s) to the EOS method. very efficient. I also like to put a line that says: ASSERT(METHOD Get attribute(Current method path;Attribute executed on server)) to indicate that the method is EOS. likewise, I guess you could have assertions to check the read write state, current selection and current record, etc. ASSERT feels weird because it's like placing traps everywhere for yourself to fall in, but it's really important that you do. > 2017/12/06 5:17、Kirk Brooks via 4D_Tech <[email protected]> のメール： > > So when I set a process to > READ ONLY(*) this is only true for the client side instance of the process. > The server side twin is still the default of READ WRITE(*). ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
