Get(RecordOpenState) and Set Field

[DG]

Hello

If I click in a portal field and change its value, Get(RecordOpenState) evaluates to 2 as expected.

However, if I script:

Go To Portal Row[select; First]

Set Field[related:field; "something"]

after the script has completed, the record is still open (I can revert it) but Get(RecordOpenState) shows 0.

This difference in behaviour doesn't seem to be indicated in the FileMaker Help entry for Get(RecordOpenState).

What am I missing?

Thanks

Simon

[JesseSFR]

I can't seem to reproduce your results. I attempted in version 8.5 and 9. It sounds very strange that this would be happening because all the related records and the base record should be opened immediately upon changing any data. What version are you using?

[Vaughan]

How are you looking at Get( RecordOpenState )? It matters enormously because some Get functions only work correctly when called during a script. I think this may be one of them.

Use the Show Custom Dialog to display the Get( RecordOpenState ) value.

[DG]

Hi

Sorry, I've updated my profile. This is on OSX 10.4.10 with FMPA9.0v1. File is not hosted.

I'm sure I'm missing something glaringly obvious but I just can't see why this is giving what appears to me to be a wrong result.

I've attached a very simple example that (on my system at least) demonstrates the issue.

@Vaughan - I've tried in both Data Viewer and in a Custom Dialog box and I get the same result.

Thanks

Simon

GROS.fp7.zip

[Brian C]

Interesting - I see the same thing. After using SetField get(openrecordstate) does indeed report a 0 prior to issuing a commit record/request

I believe that Set Field has a built in commit - though it seems the mechanism does not affect the revert record flag and the cached data for performing a revert record.

This is actually useful... This means you can make multiple changes with Set Field and still be able to use revert record to undo changes to a record during an edit process. In this way, your solution could pre-populate fields and allow the user to either finish the data entry or undo/cancel the edit.

To be honest I have always used my own RecLock flag field to track if a user is making changes or not to a record.

Are you attempting to check the open state for running your own admin processes or for making sure users don't step on each other?

[DG]

Hi Brian

I was checking that the record wasn't uncommitted before a script did some stuff but there are other (probably better) ways I can handle it.

I just thought it curious that Get(RecordOpenState) didn't give the result I expected.

Glad you saw it too. Thought I might be going mad.

Simon

[comment]

It looks like a bug. It's worse than described: you can open a new window, and it will let you edit the parent AND any [color:red]other child - and commit them. Come back to the original window, and you can still revert the record.

Edited July 27, 2007 by Guest
Added clarification

[mr_vodka]

Has anyone reported this yet? It seems pretty serious.

[LaRetta]

This would blow my understanding of record possession and locking.

We need to either 1) become clear on the meaning or 2) know that an Update is in the works. Far too much depends upon this understanding ...

LaRetta

[DG]

Agreed, I'm hesitating to submit a bug report until I understand exactly what should be happening versus what appears to be happening.

Can anyone throw any more light on the matter?

[comment]

It's not as bad as I thought (see my edit). It seems only the modified child record is locked. The parent and any other children are unlocked.

At some level it makes sense, since Set Field[] operates directly on the child record. You don't need the portal (other than to direct the Set Field[] step to a particular child).

So the question is - would you expect the parent record to become locked every time you do this:

Set Field [Related::Field ; NewValue]

Incidentally, the Get ( RecordOpenCount ) function does not behave as advertised: it looks like it counts open child records as well, so you can have more records open than there are records in your found set.

A test in a true multi-user scenario would be useful, I think.

[DG]

But Get(RecordOpenCount) does return a non-zero count even if a Set Field has altered a related record. So in that way I guess it behaves the way I had expected Get(RecordOpenState) to.

So using both you can determine if it is a record in the current context's table or a related table that has been altered.

Count = 1 and State = 0 Child

Count = n and State = 0 : n Children

Count = 1 and State = 2 : Parent

Count = n and State = 2 : Parent and n-1 children

Is that right? Seems quite useful.

Edited July 27, 2007 by Guest

[comment]

I am not sure that's entirely reliable. Say you have 2 children in a portal. You start by editing the first portal row (manually, or by Insert Calculated Result). Now you have Count = 2 and State = 2. But in fact all three records are now locked.

And what if there are open records from another relationship?

Edited July 27, 2007 by Guest

[DG]

Yes, good points. Unless you can be certain that only scripting or only a user has made changes then no use at all.

So I guess we're back to the question of:

1) Does Get(RecordOpenState) behave as intended?

2) If so, is the help entry misleading?

[comment]

I would say yes to (1) and no to (2). The misleading element here is the portal - that's what threw me at first. But the existence of the portal is irrelevant, when you are talking about Set Field.

FMI's "Migration Foundations and Methodologies" white paper describes the result of using Set Field on a related field

"Will not open the current record (if not previously opened); opens related record (and leaves it open)." (p.79)

I believe this describes your experience quite precisely. Since Get (RecordOpenState) returns the state of the CURRENT record, and the current record is the parent record, the expected result is indeed 0 - unlike when editing directly in a portal row, which "Opens the current record and the child record whose field is being edited." (p.78)

[DG]

Excellent, makes perfect sense. Maybe the help could do with a bit of fleshing out.

Thanks comment.