Kevin, I did not get an answer to this question yet....

One question though. How do you assign a NULL value to a column in an update?

I'm not that fond of this approach as it could trigger all kinds of constraint and triggers on columns that essentially are not replaced. I'm not sure whether the transaction log is filled with the old and new values, but it would not surprise me.

Walter,


>In a SP you generally pass all fields as parameters, and are forced to update the whole record. You can use a timestamp to check whether the record has changed in the mean time (correct?) Generally this is done in the way of...
>
>Most of my clients have workflow where they don't want two users editing the same record at the same time. But, I'm sure that someone might need it.
>
>It isn't necessary to pass all fields as parameters. There are different ways this can be done.
>
>One possibility is this - you can default parameters to NULL, and use COALESCE, if there's a big concern about only updating what was changed.
>
>So in an update proc, you might have your parameters as...
>
>

  @firstname char (25) =null, @lastname char (25)=null
>

>
>And in your update statement, you can have....
>
>

>   UPDATE MyTable SET FirstName = COALESCE(@firstname,firstname),  SET LastName = COALESCE(@lastname,lastname) WHERE PrimaryKey = @PrimaryKey
>

>
>Now, if someone doesn't want to use COALESCE [though I prefer it for readability], you could examine each column and construct a SQL statement based on the parameters that weren't NULL. I don't care much for that, but it's an alternative. Again, if you're generating these procs based on a data dictionary, it's a snap. Either way, it becomes the standard API for updating a table.
>
>Then the application would only send up those columns that were modified.
>
>Kevin