If any records are busy in a given found set, Server will not allow a delete of that found set. Is there a way to identify those busy records and except them from the found set to be deleted?

[FM8.5, FMS8, 30 node Mac network]

Any clues about this are greatly appreciated.

~Dennis

Hi Dennis,

The Get(RecordOpenCount) should do it for you...

Won't that only tell you the number of open records, not their identities? Get(RecordOpenFieldValue; FieldName)?

A function like this (if it existed) would allow the serial numbers of the open records to be returned in a list...

Ah Ha!!!

Get(RecordOpenState)

New in FileMaker v8

~Dennis

Get (RecordOpenCount) doesn't seem to work for me.

I'm in a netwoked environement, I use Filemaker server with two clients A and B.

On machine A I've went on a record and entered one of its field (cursor in it); I've type something but didn't go out the field

On machine B : I launched the Get (RecordOpenCount) command both with dataviewer and a dialog script. I made sure that the record I'm modifying in A, is in the foundset of B, and I'm on the same layout.

I got 0.

Even if I'm on a record on b, and that I modify it on B and launch the Get (RecordOpenCount) I get 0

There's defintely something I don't understand.

Open record doesn't mean being modified ?

Run the test again only with the cursor in a field and the data changed (add a space or something).

It only seems to work if I'm on the record I'm modifying.

If I'm on record A and modify record B, if I'm record a I can't have something else than 0 while I'm in A. Of course i'm in the same foundset

I retried locally, so one machine, no server.

I created a new window same layout but with another record (which is in the foundset) and modified it.

Dataviewer in new window does show a proper open record count.

But if I activate the first windows, it wont give any other replies than 0, even thought the field is being modified.

It's as if that function only works on the record you're working on

same thing if i run a script with display dialog

Edited August 20, 200817 yr by Guest

Is there a setting on the server to do for this to work ?

like enabling statistics

it really don't work for me !

Entering a record [color:red]does not lock it. Only when you begin editing is the record locked. Or, you can issue an OpenRecord command to it.

Steven

Ok, but I even tried with editing the record

does someone succeed to get the number of opened or locked records in a networking environment with filemaker server ?

(I means user A would know if there's a locked record if USER B locks it)

does someone succeed to get the number of opened or locked records in a networking environment with filemaker server ?

No,it does not work that way. However,if you tryto edit a record that someone else has locked, FileMaker Pro will identify who has the record locked and will display thatinformation in a dialog box.

Steven

What I want to do is to know whehter or not, there's somewhere on the network locking a record, because I want to run a script that will fail if that's the case.

so before running my script I would have check if there's a least one locked record on the network, if so I would pospone may script.

This script is a scheduled scripts that gets inventory count every hours. If someone has locked a record the import will be ok till it bumps on the locked record. So I get part of data with correct inventory and the other part with old data.

I would have to look into this more, but I do not think that what you are asking can be done, at least readily. But maybe.

As for the locking of the record, remember that is a lock against writing TO the record not reading FROM the record.

Steven

The problem with checking for zero open records prior to an import is that it doesn't guarantee the record open count will remain at zero. If you're importing 50,000 records, someone could open record 25000 while your import is still at 24000, and rec # 25000 will still fail to update.

An alternative would be to set up a relationship between your source table and target table, loop through your source table records, and in each loop iteration attempt to open the target record. If open succeeds, update it, otherwise log it for later updating.

Of course, if it really is an all-or-nothing affair - all must be updated or none must be - then the above won't be an option.