Comments on: Random Numbers Repeating

By: Dick Kusleika

Dick Kusleika — Thu, 28 Aug 2008 21:49:00 +0000

fzz: I don't send these temporary identifiers into Access. I do use INSERT with every field except RoyaltyLineID which Access dutifully fills in. Here's the scenario:

Invoice has one or many InvoiceLines
InvoiceLines as one or many RoyaltyLines

When the user selects and invoice, the Invoice, InvoiceLines, RoyaltyLines and other classes are filled from Access. Then the user can add, delete, or edit the Royaltylines. If they add a RoyaltyLine, I don't immediately write that to the database, only when they 'Save'. But at this point, my RoyaltyLines collection contains both Access records and non-Access records. That means there's the potential for a clash between Access' autonumber and my temporary one.

By: Mike Alexander

Mike Alexander — Thu, 28 Aug 2008 21:17:00 +0000

Of course, my suggestion would require the field that holds your unique identifier to be text field.

My granpa always told me (in a scruffy granpa voice), "Good database design prescribes the use of number fields only for values that are to be used in calculations. Stay away from numeric identifiers because you will never add them."

Crazy grandpa....

By: Mike Alexander

Mike Alexander — Thu, 28 Aug 2008 21:05:00 +0000

DK,

(mcolRoyLines.Count + 1) * -1 would essentially give you what Dermot suggested, which is sequential negative numbers. This should be rock solid.

Since I'm lazy, I would simply prefixed the manually generated autonumbering with text; As in Admin438?

By: fzz

fzz — Thu, 28 Aug 2008 17:46:00 +0000

You're building records outside Access, and you need unique ID fields in your collection outside Access. The records in this collection would eventually be fed to Access. And you're feeding the temporary ID fields used in your collection in addition to the information fields to the Access table.

Why?

Access supports SQL INSERT statements for a subset of the fields in a table, and as long as you don't include the temporary ID field from your collection in the INSERT operation into your Access table, Access will generate new unique, NONCLASHING primary keys or autonumber fields for the new records. You may need to dump your collection into a temporary table then insert that table into your main access table, but you'd never have to worry about key clashes again.

By: Jim Cone

Jim Cone — Thu, 28 Aug 2008 16:39:00 +0000

Ok, I'll take the bait - grin

clsRoyaltyLine.RoyaltyLineID = mcolRoyLines.Count + 1 * -1
Should be...
clsRoyaltyLine.RoyaltyLineID = (mcolRoyLines.Count + 1) * -1

-OR-

This might be more efficient...

Private Declare Function timeGetTime Lib "winmm.dll"() As Long
'(Returns the number of milliseconds that have elasped since Windows started.)
clsRoyaltyLine.RoyaltyLineID = timeGetTime

By: Dick Kusleika

Dick Kusleika — Thu, 28 Aug 2008 15:48:00 +0000

One problem with sequential: Some of the class members are already in the database and will have a autonumber assigned by Access. If I use a Count to go sequential, it could clash with one of those. So I think I'll go with

clsRoyaltyLine.RoyaltyLineID = mcolRoyLines.Count + 1 * -1

The Count suggestion and the Negative suggestion combined should make it rock solid. Right?

By: Dick Kusleika

Dick Kusleika — Thu, 28 Aug 2008 15:40:00 +0000

I won’t be calling the database for this number because it would produce too many calls and performance would suffer. I agree that I should be using built-in stuff whenever possible, but the cost is too high in this case. It seems like sequential is the way to go. Not sure why I didn’t think of that.

By: Nat

Nat — Thu, 28 Aug 2008 00:36:00 +0000

Replace Access with SQL Server Express, Int ID with GUID ID, although that is probably not want you want to hear

By: dermot

dermot — Thu, 28 Aug 2008 00:34:00 +0000

To keep it really simple, why not start at -1 and count backwards(-2, -3,…). Because this negative sequence will never clash with the(positive) autonumbers

By: Mathias Brandewinder

Mathias Brandewinder — Wed, 27 Aug 2008 21:23:00 +0000

Here is a possible alternative: rather than unique numbers, use Guids. They are very convenient to use ( myClass.Id = Guid.NewGuid), and have pretty strong guarantees of being unique.