True but since we are using non connection pooled uniobjects connections the
pid is different each time anyway
-snip-
Not a bad idea, however you may encounter problems of losing data in
these 2 areas:
1. As processors get faster, the difference in execution time shortens
and it can be
I would base my decision on the method of retrieval. I like the sequential
key method, a lot of systems don't like the @ sign as part of the key. But
if you do choose the email*date*time I would suggest turning it around and
making it Date*Time*Email so that the data lines up better when
This dilemma came up on the SnupNow.com project. At the time, and now, I
favored option one. Sometimes people change their eMail address.
Consider starting the ID sequence at say 1,000 (or 10,000). If more than
9000 customers come on-board, the Ids can be back-filled with a leading
zero.
I would go for #1 because the time slice may be short and cause a problem
with key creation the other ways. It would create lots of records but small
ones and may be faster. You can then move them into another file,
periodically, deleting the single valued records and creating multi-valued
ones
PROTECTED] On Behalf Of jpb-u2ug
Sent: Thursday, August 28, 2008 10:53 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData Keys
I would go for #1 because the time slice may be short and cause a
problem
with key creation the other ways. It would create lots of records but
small
ones and may
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick Gettino
Sent: 28 August 2008 19:07
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData Keys
There is no way you should put the email address as part of the key.
You can run into key length issues, the file will not hash
-snip-
- in this instance we
use unique ids generated using date, system time in milleseconds
(system(12)
in udt) and pid combined together
Symeon.
Not a bad idea, however you may encounter problems of losing data in
these 2 areas:
1. As processors get faster, the difference in execution time
Troy wrote:
At least one time a year (in my timezone) the clock is turned back
one hour and it would be possible to overwrite existing keys during that
hour.
For those who deal with daylight savings on unix, in the fall when clocks
roll back, the clock hits 3:00am and then rolls back to
PROTECTED] [EMAIL PROTECTED] On Behalf Of Buss, Troy (Logitek
Systems) [EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 7:02 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData Keys
-snip-
- in this instance we
use unique ids generated using date, system time in milleseconds
(system(12
