UpdateMult() returns 1 affected row too many

Posts   
 
    
PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 10-Apr-2007 13:01:18   

Hi,

Since build 04032007, each call to UpdateMulti() on an EntityCollection returns a count that is 1 higher than the actual number of affected rows.

  • I updated the runtime to build 04032007 today.
  • I have run unit tests directly before the update and directly after, without any code change. I only regenerated the DAL with the designer.

  • I have checked the result by copying the T-SQL statement from SQL Profiler and execute it directly from SQL Management Studio. The number of affected rows is as I expect, so there is no database issue either.

Regards,

Patrick

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 10-Apr-2007 15:15:01   

in that code nothing has changed, and it returns the value it receives from the db client. Did you apply SP2 for sqlserver 2005 recently or some time ago? I can't find any other explanation. I can't repro it (sqlserver 2000)

Frans Bouma | Lead developer LLBLGen Pro
PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 10-Apr-2007 15:25:01   

Otis wrote:

in that code nothing has changed, and it returns the value it receives from the db client. Did you apply SP2 for sqlserver 2005 recently or some time ago? I can't find any other explanation. I can't repro it (sqlserver 2000)

I have SP2 installed, but that was a few weeks ago. As I ran the unit tests successfully just before I updated LLBLGen Pro, and did not change any code or data in between I can not think of any other cause. No matter the count of affected rows, it's always a difference of 1. So if 55 rows have been altered, UpdateMulti() returns 56, if 1 has been altered UpdateMulti() returns 2. Also do I use a number of different filters in the unit tests.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 10-Apr-2007 20:54:18   

Could you give more specifics about the code you're running, like the unittest in question? As I can't repro it, it would help me a great deal if I can use your test code to repro it.

Frans Bouma | Lead developer LLBLGen Pro
PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 11-Apr-2007 08:37:57   

The following code example fails with


NUnit.Framework.AssertionException: 
    expected: <65>
     but was: <66>


[Test(Description = "TEMP")]
public void TEMP()
{
  SubAEntity newValues = new SubAEntity();
  newValues.EndValidity = new DateTime(2010,12,31);

  SubACollection updater = new SubACollection();
            
  int affectedRows = updater.UpdateMulti(newValues, null);

  Assert.AreEqual(65, affectedRows);

  // The last line could be replaced with Assert.AreEqual(updater.GetDbCount(), affectedRows) which has the same result. 

}

Note that I have replaced the original table and entity names with substitutes.

Table SubA is a subtype of table Super. There is one other subtype, which has 11 rows.

I have tried the same code on a table which has no relations and/or supertype and then the update count is correct. Because this is the only table I use in a super/subtype construction I have some suspection in that direction, but that's just a wild guess.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 11-Apr-2007 11:40:59   

Ah, supertype/subtype, that is indeed a different story, as it then results in 2 queries (or more) and it has to add the values together. I'll see if I can repro it with inheritance (targetperentity)

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 11-Apr-2007 14:06:08   

Reproduced.

(edit) Found it. We changed abit the way queries were generated and executed for inheritance entities as there was a problem in some scenario's. What happens is that if you have an entity which is the second in the hierarchy (every level in the hierarchy will add '1' to the end result) and the update query is only affecting the subtype, the query for the supertype is empty. This then isn't really executed but '1' is returned to make sure code isn't unnecessarily failing. (the '1' is returned from the lowlevel query object executing the query so it doesn't know what happens with the result).

The batch query object, which executes all queries in a row simply adds the 1 to the other result. This isn't correct of course. However making the empty query return 0 will require other mechanisms to figure out if this 0 is a failure or simply a non-execute.

Though the batchquery object can be updated with simple code to overcome this. simple_smile

Fixed in build 2.0.07.0411

Frans Bouma | Lead developer LLBLGen Pro