How to uniquely identify new records

[Tom Archer]

Here's my situation:

* I have an SDI application where the main view is a
listview of employees

* When a new employee is added, I create the DataRow, add
that row to the data table's

DataRowCollection and then insert the relevant data into
the list view. However, as I do not

have the primary key (which is autoincrement) I specifiy a
value of -1.

* When the user selects a newly added item to delete, I
use the DataTable::Find method. However,

obviously that doesn't work for my new records that do not
have their primary keys from the data

store yet.

* Therefore, I'm trying to figure out how to locate the
row the user wants to delete.

I have come up with one solution, but it's kind of of a
kludge and I wanted to verify if there

wasn't an easier way:

1) For each new record, get the hash code associated with
the new DataRow and store that as item

data for the listview entry.

2) OnDelete -

if (-1 != EmployeeID) // record is not new
use the DataTable::Find method to locate the DataRow
call DataRow:elete
else // record is new
use the Select method with First Name and Last Name to
get a DataRow array
if rows returned == 1
call DataRow:elete on first (and only) row in array
else
get stored hashcode for item
enumerate DataRow array looking for row that has same
hashcode and delete row

This works, but seems like a lot of work to delete a
record and so I want to verify with you folks that this is
the only way (within the context of my application) to
find and delete a new row from a disconnected dataset.

 

[Francois Beauchemin]

Hi Tom , why dont you simply add your employee with a key which is
inconsistant with the database (negative value for exemple ... ) ?

So the first added row would have a key of -1 , the second a value of -2 ...
and so on !

 

[Tom Archer]

I absolutely agree. In fact, I've spoken and written for
many years on the advantages of using artificial primary
keys. GUIDs just happen to be the technique de jour. 15
years ago, it was common to maintain a separate table that
contained the next primary key to be dispensed for each
table's new record.

However, in this case I'm using a table that has already
been designed (and uses an IDENTITY column as the primary
key) and so I needeto work within that context.

 

[Michael Lang]

The simple way is to use a GUID for all your primary keys. In .NET use the
Guid.NewGuid() function to create a primary key value for your record. When
you do an update SQL will just accept the primary key you assigned. This
way you don't need any kludge code.

There is another thread talking about the best PK field datatype to use in
this group, "GUID vs other integer types for Primary Keys?"

Michael Lang, MCSD