At 03:21 PM 8/27/2012, you wrote:
>On 8/24/12 7:18 PM, Ken Dibble wrote:
> >> >There are no guarantees in life. But the danger of sys(2015) lies in 
> it's
> >> >generation
> >> >based on the timestamp. What are the chances of collision on this 
> even not
> >> >concatenating the machine name?
> > Somewhat high, I believe. System clock ticks <> processor cycles. As I
> > understand it, in VFP RAND() uses the system clock, and RAND() will
> > generate the same number over and over and over in a tight loop on a fast
> > machine, until the system clock ticks over.
>
>Well, here's the test code I used:
>
>{{{
>create cursor temp (gid c(16))
>
>for n = 1 to 1000000
>   insert into temp (gid) values (sys(2015))
>endfor
>
>select gid, count(*) from temp group by 1 having count(*) > 1
>}}}
>
>Let me know how many non-unique rows you get on your processor. I'm 
>running XP on a
>virtual machine so that could be throttling my system enough to not see 
>any issue.

None. AMD Athlon 64x Core Duo 5600+ @ 2.9 GHz.

It remains theoretically possible though. :)

>With auto-incrementing integer keys, how would you handle offline inserts 
>without
>things getting incredibly complex?

I understand the advantages of using GUIDs when you need to able to synch 
offline data.

I don't synch offline data in my apps. I'm not convinced there's an 
advantage to GUIDs in situations where centralized key generation is always 
available.

I don't use auto-increment to generate keys. I use my tried-and true 
stand-alone procedure and pk lookup table. It's based on the one in Booth & 
Sawyer's "Effective Techniques", with some modifications.

Ken Dibble
www.stic-cil.org 


_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to