Hi Keith

>>I usually use a stored procedure to add new rows to my tables. I have in some cases passed the new ID (PK) as a parameter to the SP and in other cases allowed the SP to generate an ID (PK) all by itself and then return the ID back to the app. I know this is a case of "six of one and half a dozen of the other" (or as we say around thse parts "a-horse-a-piece"), but I have decided to choose one method over the other for my future development.
>>Any thoughts about which method is better. I am currently leaning towards passing the ID as a parameter to the SP because I think this might be slightly faster.
>>
>>What do you prefer? Do you use SPs exclusively for this (insert, update)?
>>
>>Einar
>
>It seems a little pointless to generate the PK outside of the database when the only way to guarantee that it is unique is to let the database generate it.
>

That is not accurate. The database can ensure the PK is unique, regardless of it's source. That's what checks are for. Generating a PK is another separate step.


>The method that I use is to call a SP that inserts the row, stores the value of SCOPE_IDENTITY() - or @@IDENTITY if that is what you prefer, then performs a SELECT ... WHERE PK = @MyID to return the newly inserted row back to the application. This means that the application will pick up the results of any defaults, computed columns, or triggers that affect the data.
>
>As far as I can tell, this is the only method to insure that your dataset is not out of date with the database.