Record posessed when new?

[David Nelson]

When a new record is created does it mean that the person creating it automatically has possession or should they open record request? I can not figure how to even test it but if I need to set fields in the new record, should I do something to make sure someone else doesn't set the fields with other things before I can?

As always, I appreciate any input. I spent 3 hours reading great things about record lock but still could not get my answer.

[No_access]

Is this something you an set in your script to create a new record and have the fields populated?

[Vaughan]

When a new record is created does it mean that the person creating it automatically has possession or should they open record request? I can not figure how to even test it but if I need to set fields in the new record, should I do something to make sure someone else doesn't set the fields with other things before I can?

As always, I appreciate any input. I spent 3 hours reading great things about record lock but still could not get my answer.

A new record is open immediately after creation. It would be locked to other users. So there is no need to explicitly open a record after creating it UNLESS there is a process that commits the record immediately after creation but before the user gets a chance to enter data.

You should trap the New Record step for errors. If the new record has been created then it should be open and fields can be set without error. Check the error status when committing the record to trap for validation.

[David Nelson]

Hi Vaughan, you have explained very well and that was exactly what I needed to hear. And yes thank you FMP12, it is using script but even if not it seems unsafe and please allow me to ask clarification. Of everything I can learn, this seems most important.

Example: I create a new record manually and sit there - not typing, not entering a field, not even scrolling. You say I own it because it is not committed and that is good. But if User clicks outside or commits, it is no longer locked. And a layout trigger on record load which does something or commits would be very bad also. New records are considered loading a record, right?

It seems triggers can be more dangerous than expected. I could include in my scripts which are trigger-based something like: If script is running, do not fire. I started watching with debugging open, which I normally only use for something specific, and I was startled to see these nifty triggers triple-firing and looping through each other in a symphony of wasted effort and time because they kept firing each other.

BTW in this example why I ask, an error trap which normally is good was returning an error and telling script to go back to layout which caused that layout's trigger to fire which says if field is empty commit and delete it and leave layout and the other layout would fire and return and ...

Yeah. Now I know to work always with bugging on and slow down on the triggers because they don't wait to be told so you had better handle them with care. :cry:

[Vaughan]

You are correct in saying that script triggers are more dangerous than expected. They were introduced in only recently in FMP 10 (although plug-ins offered the functionality before then) and they add another level of complexity to the operation of the interface.

Unfortunately many developers, particularly the inexperienced, over-use them without understanding their consequences. I am seeing them frequently used to make up for poor database design.

As to whether the onRecordLoad trigger runs when a new record is created: I'm not sure. It's an interesting question.

[David Nelson]

Hi Vaughan, thank you for helping.

Yes, OnRecordLoad triggers for new records. The other one that caught me was OnRecordLoad fires when changing a layout even if is is based upon the same table occurrence and same record. And if you have OnObjectEnter on that first field it will fire as well.

If someone does not have the developer advanced version and they are using triggers, they are driving blind and there is no telling what is really happening.