(BUG) I hate ADO.Net 1.1 - inserting a record into SQL Server
OK here is my experience of trying to write some code to do something
really basic - insert a record into SQL server.
For various reasons I want to insert my row via a command rather than
using a dataadaptor. Part of the reason is that I am trying to write
a facade object behind which to hide the idiosyncracies of different
databases, and the class where I might use a dataadaptor to do the
insert has a DbDataAdaptor available which doesn't have the property
InsertCommand (DESIGN ERROR).
So I try to write code which will do an insert in an IDbCommand. I
find that loading in a schema for the table I am working with sets up
the primary key column as read only. Fair enough, I temporarily set
it to non-readonly and use an ExecuteScalar on SELECT @@IDENTITY to
get the primary key assigned to the newly inserted record by the
database assigned to the primary key of the new row. So far so good.
Then I try using the DefaultView of the table and find the first
DataRowView in it (which corresponds to the row I have added) is no
longer pointing at a row at all, its .Row property is Null (BUG).
Then I think ok the DefaultView has got out of synch with the table
I'll set the primary key through the DataRowView corresponding to the
new record. After finding there is no way to search the DataView for
this row, I wrote a bit of code to loop through every row to find this
DataRowView myself. To find it I make the innocent looking comparison
drv[pkeyName] == row[pkeyName]
however I find this test is never being satisfied so I debug it
remembering this one from somewhere. Debug printing the value
(drv[pkeyName] == row[pkeyName]) comes back with true however the code
skips the body of the 'if' clause (BUG). I change the comparison to a
hacky but effective drv[pkeyName].ToString() ==
row[pkeyName].ToString() which this time works. I set the new primary
key value through the drv however doing a QuickWatch on it reveals
the .RowVersion property is null. There is something hideously wrong
with RowVersioning in ADO.Net and it causes many many different bugs.
There seem to be several dodgy patches on the MS site for different
aspects of this but they seem not to have sorted out a core part of
their flagship development platform that is meant to be the basis on
which all PC development should be done going forward. Unless Linq
does something better but I havent worked with it yet.
Anyway enough ranting I'm off to try regenerating the DefaultView by
changing its Sort and various other things. If anyone knows a
workaround for this please help. Thanks.
Date:Thu, 16 Aug 2007 13:37:27 -0700
Author:
|