>On 8/24/12 5:21 PM, Ken Dibble wrote: > >> >That's why I concatenate with the machine name. I guess if you are > really > >> >paranoid > >> >that a second instance of VFP could be running sys(2015) for the same > >> >table in the > >> >exact same timeslice as the first process you could also concatenate the > >> >process id. > > Machine names are not guaranteed to be unique indefinitely; they are only > > guaranteed to be unique on a single domain at one point in time. > >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. So in a hypothetical situation where creation of a parent record automatically generates a fairly large number of child records, the timestamp on many or all of those child records will be exactly the same. Conceivably, this increases the odds that GUID keys generated for those child records will be the same. And what was less likely to happen on your "old slow" 2.6 GHz machine last year will be much more likely to happen on your "latest and greatest" 3.4 GHz machine this year. But yes, practicality beats purity--until it fails and somebody's expensive database gets corrupted. "Nobody will ever fill up a 100 gigabyte hard drive." "Nobody will ever break 40-bit encryption." "Nobody will still be using our software that relies on 2-digit-year dates in 2000." "There is no reason anyone would want a computer in their home." -- Ken Olson, CEO, Digital Equipment Corp., 1977 On the other hand, as best as I can tell given a reasonably robust locking strategy and a next-key table, User ID integers can be centrally generated for any database system that are absolutely, positively, no exceptions no matter what happens on this fair planet, guaranteed to be unique until a number is reached that is 2/3 of the population of the earth using unsigned 4-byte integers. Use an 8-byte integer and you get 18 quintillion unique numbers. Why not require users to login with a unique user name that is associated with a centrally-generated user ID integer (as, indeed, everybody already does in multi-user systems), and then, to use a VFP example, prepend (TRANSFORM(UserID)) + "|") to your GUID? Not difficult, and the value of the "guarantee" of uniqueness would be much higher than that of any GUID, or GUID + anything else I can think of, alone. It's all fun and games until somebody gets hurt, as my mom used to say. :) Why do people in the software business constantly go for "good enough for today" when simple solutions that are "good enough for 100 years" are staring them in the face? I keep asking myself, would it really have killed programmers in 1970 to allocate 2 bytes for a year? Don't even get me started on "32-bit" vs "64-bit" operating systems. Windows 98 could address every spot on a 128 GB hard drive, so why can't Windows XP address more than 4 GB of RAM? And even if there is some technical reason for this (as opposed to deliberate planned obsolescence): Since everybody right now knows that someday people are going to want to use 128 bits, why haven't they built in the ability to do that, or even 256, or 512 bits, into today's operating systems? I can't imagine it's anything more than extending the bounds of an existing algorythm. Think about it: compatibility for the next 50 years instead of the next 5! But oh man... somebody's not going to be able to squeeze as much money out of that strategy.... Ken Dibble www.stic-cil.org _______________________________________________ Post Messages to: ProFox@leafe.com 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/5.2.1.1.1.20120824213758.01fa2...@pop-server.stny.rr.com ** 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.
