[Mono-list] How do you debug?

[Ivan Hawkes]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 04 Jul 2003 11:06 pm, Miguel de Icaza wrote:
> Hello,
>
> > Ok, it definitely looks like Mono being a little naughty but it's a
> > simple fix.
> >
> > The offending code is:
> >
> > uniqueId =3D reader.GetInt32(reader.GetOrdinal("RealContentItemId"));
> >
> >
> > and the fix is:
> >
> > uniqueId =3D reader.GetOrdinal("RealContentItemId");
> >
> > It seems that GetOrdinal is returning an Int32 and we then try to conve=
rt
> > to a (wait for it) Int32. Mono should just ignore this code but it
> > doesn't. Actually, the programming team never should have written it li=
ke
> > this, but hey, Mono should handle this kind of stupidity.
>
> Lets examine the problem a bit more, because I was as perplexed as you
> were that a conversion from int to int would throw that exception.
>
> What is happening here is that "reader.GetOrdinal
> ("RealContentItemId")" returns an integer.

Correct, an Int32 to be exact IIRC. MSDN has the following definition:

public virtual int GetOrdinal(
   string name
);

and the GetInt32 function is:

public virtual int GetInt32(
   int i
);

Now that's not what I'd call a useful function to start with...they're goin=
g=20
to convert an int to an int??? In any case, it works on MS platform and=20
doesn't for Mono.

> And here is the problem: the returned int is used as the ColumnValue
> *key* whose value happens to be something different.

The returned int is indeed used as a column key. This key is then used to=20
return the actual value of the column...now this is weird. I seem to recall=
=20
from the tests that the value coming back from GetInt32 was not the actual=
=20
value that the table held but may have been the column index instead. Now=20
I'll have to go write that code again and find out, because looking at the=
=20
MSDN reveals that the GetInt32 should have return the contents of the field=
,=20
not the column ID.

I'll keep you informed...

> Am not a System.Data expert, but this is either a bug on the original
> runtime, or there is a miss-conception in the
> System.Data.SqlClient.GetValue code.
>
> I added some extra information to the exception on CVS
>
> Miguel
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQIVAwUBPwYFlPr1e7bH1pzBAQJHqQ/7BwKT1x9DzSRlqBDvOiEhXpO6L/mjV/fQ
+3ilMUS0cPUA4R7ypfJlSo9mpsJK05BAWvNxLtF2ywWoSYW1SgmV6zaxMM/dgBs2
4JrEWdOLjWbIM3TmwJvmAyY8LZMvUf67jLBNjpgZTCMCpH2Yv5EViMSx4vRat9AY
Na7BMET8Hk9F8SWVJ3M39+f5UKGOUWTb1kLb+QFFPS8MnX5RwM3i3eIbXXQck0in
KixrYjxvRKrhplSvzbgltHXX85/ohKQH8NIxmujZAKwiYuWB2NVloTWtHSAaKabR
6FVQABbqatlKTg31QLmr/vEGmPLK7NUbXgO31e+hWYUgfXP07KZd+WgKp1eredEy
M4hSkHiM06auwR9pJ0YkUGofwFk0mGQ0QQgzzvvetvIiJYI83MzKysybRhP4qJyK
SpckcujX02u1Q3SBoj3OSttVuoGeKe5JhUjFuC9vHameKwDDwvJpGMXgW1Emt5ig
ecNGzuhlm6eXgLUf3pnWNkJ50knn1QEimTPQcdPP5CcBSEfgFjTFf8FSzbO5ycCz
+Xqy+XV2beZfa4ALzHWV8oxY+/KqT3UdDk72h448Zwca0LgILROSL2czMeGX+/6J
O/j8FHxHraG7P84GN7G6lOeOo/O7F4W2egJX99LXmL364IiKu6mzSX1znmXyVljI
ML/M3pI5Osw=3D
=3Drtmy
=2D----END PGP SIGNATURE-----