Larry,
Thanks for the ideas. I really didn't think of using an autonumber from a different column, but it probably wouldn't work for this particular app. The end user ("messagee") has to mark the row completed and this can be seen by the sender. I was trying to keep the numbers of tables down, and keep it simple at first...but as always, things get more complex. I may wind up doing that anyway.
The time data was only part of a computed column identifier, concantenated with the sender's first name, so it would not accidentally be the same some day.....
BC
| Lawrence Lustig <[EMAIL PROTECTED]>
Sent by: [email protected] 01/03/2005 11:45 AM
|
|
> What I am doing is creating a
> unique identifier, entering a row of data, and then duplicating that row
> to different users. When I use the autonumber, it gives a different
> number on duplication. The only reason I need this to be the same is if
> the originator EDITS the message, it will need to update in possibly
> several rows.
Bob, if those messages are really identical (that is, they will never diverge
with one user having one copy and another user having a different copy with
different contents) consider storing them _once_ in the message table and then
linking them to different users with a table UserMsgLinks with two columns
MessageID and UserID. This will cut down on storage, eliminate the need for
all of that update code, and eliminate the possiblity that people will see
different versions of what must be the same item.
Even if you do need to keep different copies of the messages, you can do that
without using the time as the unique ID. You can use the NEXT function to draw
autonumber values out of a separate, empty table -- by putting the NEXT call
either into a computed column or an INSERT trigger.
Alternatively, use a normal autonumber column and, when you copy a record, copy
the ID value of the original record into a _different_ column (say ParentID)
and let the new record get a unique ID value of its own. That way, when you
update a record you can simply update all the records with the same ParentID.
Although it's a longshot that you'll get two time values the same down to the
thousandeths of a second, it is in no way impossible for this to happen. Using
a guaranteed unique number could possibly save yourself some aggravation down
the road.
--
Larry
