views:

200

answers:

1

Hi folks

Today's problem in my code is kind of strange, and I could not reproduce it yet. I'm working with a typed dataset (created with the designer) and I'm looping over all rows in a datatable.

Sometimes (!), when finding via primary key, the returned row is not equal to the one from the enumerator. This is some code I wrote to reproduce the issue:

foreach(DataSet1.DataTable1Row dr in ds.DataTable1)
{
    if(ds.DataTable1.FindById(dr.Id) != dr)
        Console.Write(dr.Id);
}

No line will be written to the console, because FindById always returns the same row, which is really logical. In my project's code, with a similar dataset with a few String columns, in about 3% of the rows (always the same rows!) it doesn't, and one of the String fields is just empty:

ds.DataTable1.FindById(dr.Id) != dr // returns false, for whatever reason

The primary key is the only primary key field, and therefor FindById is a generated method. Does anybody know a little hint or did experience the same problem before? I'm afraid it's a very very special case I made that enables this bug or feature. :)

I thought about the possibility of this being produced by the cast done by the enumeration. The enumerator does work with the DataRow base type of the generated typed rows. But I didn't find something wrong there...

Cheers Matthias

+2  A: 

WHat's the type of you primary key? the DataSet has a subtle bug for comparing Guids (and possibly other values). The Guid error only has to do with certain Guid values and usually works well.

note: When I say have a bug, I mean I know that a bug report has been accepted but I don't know if it's been fix as well

Rune FS
Thank you! The type is string, but in fact there are GUIDs stored in the field. This is given, I cannot change.
Mudu
The work around I proposed when i submitted the error (some 3 years ago if im not mistaken) was to use SQL to transform the GUID into string. that does unfortunately have a very real impact on the performance of the SQL. If you can't do that you couild (at least for debuging) convert the table to a dictionary with the key of the dictionary being the primary key and the value being the row. As far as I remember the problem was not related to GetHashKey
Rune FS