File under: "Don't try this at home, kids."

7 messages

File under: "Don't try this at home, kids."

Reply Threaded

A couple developer friends of mine have come across an interesting
failure in FMPA10. They have not tested it in FMP10 or any earlier
versions, but one might expect similar results.

The issue arose when they needed to do an import. They did not want to
re-fire all the lookups and updates so they turned that off in the
import. Still, they needed to re-serialize the results, so they ran a
subsequent Replace step to do that, setting it to reset the field's
autoenter serial number key field.

What they found was that the next serial number setting was NOT reset
until the replace was entirely done. Any records created by other
users during the time that the Replace was running ended up with
duplicate keys.

Now, some of you may read this and say, "Well, DUH!"

This is for the rest on the list that don't think this is so obvious.

You cannot rely on this technique in a multi-user environment. You
need to find a different way--lock the table during the Replace, trap
for new records, use only UUIDs, or something--besides relying on FMP
to take care of it for you.

It won't.

j.

--
Jonathan Fletcher
FileMaker 9 & 10 Certified Developer
****NEW Ph no: 502-509-7137****

Project Foreman
NewMedia Construction Co.
[hidden email]

Instigator
The BB&J Network
The "Go-To Guys" for
FileMaker Development in Louisville
www.thebbandj.net

FileMaker Louisville Blog:
http://filemakerlouisville.posterous.com

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

Chaim Bacon-2

Re: File under: "Don't try this at home, kids."

Reply Threaded

Hi Jonathan,

Or you could do the following:

1. Get the next serial number ($nxt)
2. Get the found count of imported records ($fc)
3. Set the next serial number of the key field to $nxt + $fc
4. The above will take a split second, so anyone who creates a new
record while you're busy with the next step will not get a duplicate
key.
5. Replace / reserialize the imported records starting $nxt, increment
by 1.

Kind regards,

Chaim Bacon
Director
Productive IT (UK) Ltd.

FileMaker 7 Certified
FileMaker 8 Certified

****************************************************************
* Business Process Engineering
* Custom software development
* Systems integration
* Productivity enhancement
*
* email: [hidden email]
* www.productiveit.co.uk
*
****************************************************************
* 75 The Campions, Borehamwood, Hertfordshire, WD6 5QG, England
* Tel: 08458 62 52 52
* Mobile: 07956 655 150
****************************************************************

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

Darren Terry-3

Re: File under: "Don't try this at home, kids."

Reply Threaded

In reply to this post by Jonathan Fletcher

On Oct 22, 2009, at 9:00 AM, Jonathan Fletcher wrote:

> A couple developer friends of mine have come across an interesting
> failure in FMPA10. They have not tested it in FMP10 or any earlier
> versions, but one might expect similar results.
>
> The issue arose when they needed to do an import. They did not want
> to re-fire all the lookups and updates so they turned that off in
> the import. Still, they needed to re-serialize the results, so they
> ran a subsequent Replace step to do that, setting it to reset the
> field's autoenter serial number key field.
>
> What they found was that the next serial number setting was NOT
> reset until the replace was entirely done. Any records created by
> other users during the time that the Replace was running ended up
> with duplicate keys.
>
> Now, some of you may read this and say, "Well, DUH!"
>
> This is for the rest on the list that don't think this is so obvious.
>
> You cannot rely on this technique in a multi-user environment. You
> need to find a different way--lock the table during the Replace,
> trap for new records, use only UUIDs, or something--besides relying
> on FMP to take care of it for you.
>
> It won't.

Hi Jonathan:

Or, you can simply include the lookups and auto-enter fields in the
import order and line them up with empty columns from the source.
Then leave the Serial Number field out of the import order, and check
the box to perform auto-updates on import. Only fields OUTSIDE the
import order get their auto-updates executed. For those fields inside
the import order, the imported data wins (even if it's empty).

regards,
Darren

******************************
Darren Terry [hidden email]
Pacific Data Management, Inc. http://www.pdm-inc.com/
111 W. St. John St. Phone: (408) 283-5900 x303
Suite 404 Fax: (408) 283-5903
San Jose, CA 95113
***** FileMaker 10 Certified Developer *****

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

Jonathan Fletcher

Re: File under: "Don't try this at home, kids."

Reply Threaded

Interesting! I'll pass that on.

On Oct 22, 2009, at 1:18 PM, Darren Terry wrote:

>
> On Oct 22, 2009, at 9:00 AM, Jonathan Fletcher wrote:
>
>> A couple developer friends of mine have come across an interesting
>> failure in FMPA10. They have not tested it in FMP10 or any earlier
>> versions, but one might expect similar results.
>>
>> The issue arose when they needed to do an import. They did not want
>> to re-fire all the lookups and updates so they turned that off in
>> the import. Still, they needed to re-serialize the results, so they
>> ran a subsequent Replace step to do that, setting it to reset the
>> field's autoenter serial number key field.
>>
>> What they found was that the next serial number setting was NOT
>> reset until the replace was entirely done. Any records created by
>> other users during the time that the Replace was running ended up
>> with duplicate keys.
>>
>> Now, some of you may read this and say, "Well, DUH!"
>>
>> This is for the rest on the list that don't think this is so obvious.
>>
>> You cannot rely on this technique in a multi-user environment. You
>> need to find a different way--lock the table during the Replace,
>> trap for new records, use only UUIDs, or something--besides relying
>> on FMP to take care of it for you.
>>
>> It won't.
>
> Hi Jonathan:
>
> Or, you can simply include the lookups and auto-enter fields in the
> import order and line them up with empty columns from the source.
> Then leave the Serial Number field out of the import order, and
> check the box to perform auto-updates on import. Only fields
> OUTSIDE the import order get their auto-updates executed. For those
> fields inside the import order, the imported data wins (even if it's
> empty).
>
> regards,
> Darren
>
> ******************************
> Darren Terry [hidden email]
> Pacific Data Management, Inc. http://www.pdm-inc.com/
> 111 W. St. John St. Phone: (408) 283-5900 x303
> Suite 404 Fax: (408) 283-5903
> San Jose, CA 95113
> ***** FileMaker 10 Certified Developer *****
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Jonathan Fletcher
FileMaker 9 & 10 Certified Developer
****NEW Ph no: 502-509-7137****

Project Foreman
NewMedia Construction Co.
[hidden email]

Instigator
The BB&J Network
The "Go-To Guys" for
FileMaker Development in Louisville
www.thebbandj.net

FileMaker Louisville Blog:
http://filemakerlouisville.posterous.com

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

Jonathan Fletcher

Re: File under: "Don't try this at home, kids."

Reply Threaded

In reply to this post by Chaim Bacon-2

I like that, Chaim!

I'll pass that on to the guilty parties!

j.

On Oct 22, 2009, at 1:14 PM, Lists (Productive IT) wrote:

> Hi Jonathan,
>
> Or you could do the following:
>
> 1. Get the next serial number ($nxt)
> 2. Get the found count of imported records ($fc)
> 3. Set the next serial number of the key field to $nxt + $fc
> 4. The above will take a split second, so anyone who creates a new
> record while you're busy with the next step will not get a duplicate
> key.
> 5. Replace / reserialize the imported records starting $nxt,
> increment by 1.
>
> Kind regards,
>
> Chaim Bacon
> Director
> Productive IT (UK) Ltd.
>
> FileMaker 7 Certified
> FileMaker 8 Certified
>
> ****************************************************************
> * Business Process Engineering
> * Custom software development
> * Systems integration
> * Productivity enhancement
> *
> * email: [hidden email]
> * www.productiveit.co.uk
> *
> ****************************************************************
> * 75 The Campions, Borehamwood, Hertfordshire, WD6 5QG, England
> * Tel: 08458 62 52 52
> * Mobile: 07956 655 150
> ****************************************************************
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

Darren Terry-3

Re: File under: "Don't try this at home, kids."

Reply Threaded

Be aware that the Replace function is not multi-user safe. It skips
locked records without reporting which records were skipped -- and if
the current record (at the time the Replace is executed) is locked,
then the entire Replace fails.

Much safer/better to use a looping Set Field script.

On Oct 22, 2009, at 10:32 AM, Jonathan Fletcher wrote:

> I like that, Chaim!
>
> I'll pass that on to the guilty parties!
>
> j.
>
>
> On Oct 22, 2009, at 1:14 PM, Lists (Productive IT) wrote:
>
>> Hi Jonathan,
>>
>> Or you could do the following:
>>
>> 1. Get the next serial number ($nxt)
>> 2. Get the found count of imported records ($fc)
>> 3. Set the next serial number of the key field to $nxt + $fc
>> 4. The above will take a split second, so anyone who creates a new
>> record while you're busy with the next step will not get a
>> duplicate key.
>> 5. Replace / reserialize the imported records starting $nxt,
>> increment by 1.

regards,
Darren

******************************
Darren Terry [hidden email]
Pacific Data Management, Inc. http://www.pdm-inc.com/
111 W. St. John St. Phone: (408) 283-5900 x303
Suite 404 Fax: (408) 283-5903
San Jose, CA 95113
***** FileMaker 10 Certified Developer *****

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

Jonathan Fletcher

Re: File under: "Don't try this at home, kids."

Reply Threaded

I agree and that's what I told them, but they suggested I let the
community know about the serial number issue.

Thanks!

j.

On Oct 22, 2009, at 1:36 PM, Darren Terry wrote:

> Be aware that the Replace function is not multi-user safe. It skips
> locked records without reporting which records were skipped -- and
> if the current record (at the time the Replace is executed) is
> locked, then the entire Replace fails.
>
> Much safer/better to use a looping Set Field script.
>
> On Oct 22, 2009, at 10:32 AM, Jonathan Fletcher wrote:
>
>> I like that, Chaim!
>>
>> I'll pass that on to the guilty parties!
>>
>> j.
>>
>>
>> On Oct 22, 2009, at 1:14 PM, Lists (Productive IT) wrote:
>>
>>> Hi Jonathan,
>>>
>>> Or you could do the following:
>>>
>>> 1. Get the next serial number ($nxt)
>>> 2. Get the found count of imported records ($fc)
>>> 3. Set the next serial number of the key field to $nxt + $fc
>>> 4. The above will take a split second, so anyone who creates a new
>>> record while you're busy with the next step will not get a
>>> duplicate key.
>>> 5. Replace / reserialize the imported records starting $nxt,
>>> increment by 1.
>
>
>
> regards,
> Darren
>
> ******************************
> Darren Terry [hidden email]
> Pacific Data Management, Inc. http://www.pdm-inc.com/
> 111 W. St. John St. Phone: (408) 283-5900 x303
> Suite 404 Fax: (408) 283-5903
> San Jose, CA 95113
> ***** FileMaker 10 Certified Developer *****
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au