FMPRO-L Archives

December 2011, Week 5

FMPRO-L@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Geoff Graham <[log in to unmask]>
Reply To:
FileMaker Pro Discussions <[log in to unmask]>
Date:
Fri, 30 Dec 2011 16:22:19 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
I don't believe you can lock a group of records. What you can do is instead of using a replace, is to use a looping script to lock, update, and commit each record; recording the failure or success of the operation as needed. You could use a replace, if the data being updated triggers a calculated field to update, that can then be used to verify if the record got updated after the fact. But a replace won't tell you which record was missed due to a lock; only that one or more of them were skipped.

There's always more than one way to do something though. When I've had a similar need, the initial set of records to be updated was arrived at using a find in the first place. So, I run the find, set error capture on, do the replace, then look at the error captured. If there was an error, I simply repeat the last find, and display the un-updated records to the user. If this was an automated process, I'd likely wait some period of time and then try the update again. (Then I'd rethink my overall strategy of attempting to auto-update records that users are editing).

Geoff

> -----Original Message-----
> From: FileMaker Pro Discussions [mailto:FMPRO-
> [log in to unmask]] On Behalf Of Helping Hand Database Design
> Sent: Friday, December 30, 2011 11:02 AM
> To: [log in to unmask]
> Subject: Re: Serial number
> 
> Hi,
> Not trying to hijack or anything, but on the record locking
> looping commentary, if I might ask. How best to lock a group of
> records in the script before zapping it with a replace?
> Thanks,
> Laura Z.
> 
> 
> 
> 
> 
> ---- On    , Todd Geist ([log in to unmask]) wrote:
> 
> One further refinement :-)
> 
> On Tue, Dec 27, 2011 at 5:30 AM, Corn Walker  wrote:
> 
> One refinement is that entering a field is no longer sufficient
> to lock a
> > record. You should use the Open Record[] command to do so,
> which should
> > return error 301 if the record is in use.
> 
> 
> Don't just check for a 301 error. Check for any error. If any
> error occurs
> you didn't open the record. So check for Get(LastError) = 0. If
> it is 0,
> your safe. If it is not 0, your not.
> 
> For example, Record Level Access would also stop a script from
> opening the
> record and it does not return 301. It returns 200.
> 
> Todd

ATOM RSS1 RSS2