>From reading this group and the documentation on msdn
(http://msdn.microsoft.com/library/de...classtopic.asp)
I see that the DataAdapter (for ADO.Net) will throw a
DBConcurrencyException for an update or delete command when the number
of rows affected is zero in the data base. I need to learn how to turn
that expected behavior off in ADO.Net 1.1.
I need to be able to submit a delete command (think sql of "delete
tableName where primaryKey = 'primaryKeyValue'") that may not affect
any a row in the data base for a given table. I do not want to have to
go against the data base twice (once to see if a row exists and second
to delete a row) - I am anti-IO and like to keep it to a minimum.
Here is my use case:
I am using optimistic locking for a three tier app (it was decided that
last in will always win - business decision). Smart Client (.Net)
frontend, webservice middle (.ASMX), with Oracle on the backend. The
middle consumes the dataset from the database to create an xml document
and passes that document to the smart client. The smart client sends
the xml document back to the webservice (it could be a brand spanking
new document for all the webservice cares). The webservice flattens
the xml document into the various database tables. But first, we must
delete all the data first assocated with the primary key (it is
referenced in many database tables) so that I can now add it back to
the database. This all happens (delete and insert) in a single
transaction. I only want to touch the database associated with the
data twice - once when I fetch the data for dispursement and second
when I put it back.
I am gun shy with IO performance. When I have a command(s) to execute,
I open a connection and close it upon completion of the command(s). I
do not have any open connection laying around. All exceptions roll
back the transaction with no possibility for parole.
So correct me if I am wrong, but it looks like to avoid
DBConcurrencyException I need to go to the database three times - once
for dispursement (IO for database), a second time to get identical data
that we got when we dispursed the data the first time (IO for
database), and then the third time to delete and insert (IO for
database). I will not keep data laying around hoping it will come
back; plus that would violate heuristic OO practices.
With all that said, does anyone see another alternative? (We do have
the ability to send the dataset to the client, but the client won't
remember the dataset either, it will treat all xml documents as a new
fresh begining.) Is there an ADO.Net setting I can use but cannot find
in the documentation? Any idea(s) will be appreciated.
Cheers,
Gerald
