On Fri, 2009-11-13 at 14:30 +1000, Angus Mann wrote: > > Here's part of the confusion: > > > > If you were to express the number of microseconds since 1970 in a > > decimal number, it would indeed take 16 digits. > > > > But uniqid() returns a /13 character string/, not a 13 digit number. The > > string is actually a hexadecimal number (and thus can express a greater > > range of values than a decimal number within those 13 characters). > > > > -John > > Ahh! The moment when the penny drops. I was looking at the result as a > number, not a string. > Solution to problem = use uniqid() > > > You say you don't want to use the auto increment field for this 'unique' value, but then you are considering using something which is likely to produce the exact same value as someone else may have in their database, and then you plan on merging the data! If I were you I'd either: a) find another way instead t create a number that is unique to you, something like a namespace kind of thing b) don't merge the data directly, but think of a smart way of adding it that avoids collisions Personally, I reckon it's best going with the latter. The other database should have extra fields in: one for their own auto incremental field, one to store the value of your auto increment (not unique to avoid problems if they source data from many other exterior databases) and one field to indicate where the data came from. I really do think that a bit of work on the interface between your two databases would reap dividends, as it could make it a whole lot easier to determine where a problem came from if one occurs, and to my mind makes things just a little bit easier in the long run. Thanks, Ash http://www.ashleysheridan.co.uk
