Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Trivia question about inner workings of ADO.NET
Message
From
05/01/2005 20:36:35
 
 
To
All
General information
Forum:
ASP.NET
Category:
The Mere Mortals .NET Framework
Title:
Trivia question about inner workings of ADO.NET
Miscellaneous
Thread ID:
00974577
Message ID:
00974577
Views:
68
I made a mistake in my programming, but I don't understand why neither .NET nor MM complained about it.

I was testing a process for updating a table in the database. I meant to run my program on a copy of an old version of the original table to make sure my program updated it correctly. I planned to compare the original and the copy of an old version after running my program was run on it, looking for them to match. I forgot to change the name of the table in my stored procedure for pulling data from the original to the copy.

Because of my mistake, I was pulling data from a table ("TableOriginal"), putting it in a business object's dataset with TableName = "TableCopy", which had the same structure and number of rows as "TableOriginal", revising the DataTable in my DataSet, and then saving the table.

When I called BizObj.SaveDataSet("TableCopy"), the result came back as mmSaveDataResult.RulesPassed. When I dug deeper into mmData.cs and looked at the value of RowsUpdated in mmDataAccessSql.SaveDataSet after the save, it came back with the right number of changed rows. I looked at the values in my business object's DataSet and they were properly updated.

The problem is, that none of the rows in "TableCopy" were changed. I would like to understand what is going on.

My first theory is that, somehow, when the SQL statement was created to update the database, .NET or MM were smart enough to update "TableOriginal", since that's where the data was pulled from. This indicates the business object's TableName, UpdateSelectStatement, and ConcurrencySelectStatement were being ignored or overridden.

My other theory is that the update statement only changes rows that were in the same state as when the data was originally pulled, so it didn't make any changes to rows in "TableCopy" that differed from "TableOriginal". This would seem to be a problem with ADO.NET considering an attempt to update a row that had been altered since the data was pulled as a success.

I wouldn't think that a program should never be written this way intentionally, but I would have expected some kind of exception or other complaint somewhere. It was bewildering to debug because the save was reported as working fine, but nothing was being updated (or a different table was being updated).

Can anyone explain this behavior?
David S. Alexander
Kettley Publishing
20271 SW Birch Street, 2nd Floor
Newport Beach, CA 92660-1752
Reply
Map
View

Click here to load this message in the networking platform