[Mysql-cocoa-users] =?ISO-8859-1?Q?R=E9p_:_[Mysql-cocoa-users]_Bug_with_BigInt_data_?= =?ISO-8859-1
Brought to you by:
sergecohen
|
From: Serge C. <ser...@us...> - 2003-08-22 08:26:25
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For some reasons... it looks like it did not get through this morning...
Repost
Hi Lorenz;
I've fixed the BIGINT issue.
Thanks for your testing perseverance. I'll join the diff on the latest=20=
version of the sources:
All version branches are corrected in CVS (version 1. -> 1.0.1, 2.1.0 -=20=
- -> 2.1.1 and 2.2.0 -> 2.2.1).
I will shortly release the sources and binary package for the corrected=20=
version 2.2.1.
Unless you're using version 1. for yourself, I will not release file=20
package of this one (version 2.2. has a script to make the packages...=20=
I have to do things by hand for version 1 + I'm really hoping nobody=20
uses version 1 anymore).
Still, if you use version 1, and not using CVS, I can send you the=20
corrected sources for it.
Serge.
PS: I've tried both strtoll and strtoq.... despite its name strtoll is=20=
NOT ok for long long (make a 32bit truncation of the result), so at the=20=
end only strtoq can do what we wanted.
PPS: I'll try to check if their is a way to know if the field retrieved=20=
is unsigned, in which case I will adapt the code to also handle the=20
unsigned int and bigint. If someone knows how to do that... please=20
spear me the search by myself (enlighten me... :-).
diff --context=3D3 -r1.3 MCPResult.m
*** MCPResult.m 16 Jan 2003 12:18:23 -0000 1.3
- - --- MCPResult.m 21 Aug 2003 06:25:51 -0000
***************
*** 257,272 ****
}
else {
char *theData =3D =
calloc(sizeof(char),theLengths[i]+1);
memcpy(theData, theRow[i],theLengths[i]);
theData[theLengths[i]] =3D '\0';
switch (theField[i].type) {
case FIELD_TYPE_TINY:
case FIELD_TYPE_SHORT:
- - - case FIELD_TYPE_LONG:
case FIELD_TYPE_INT24:
case FIELD_TYPE_LONGLONG:
! theCurrentObj =3D [NSNumber=20
numberWithLong:atol(theData)];
break;
case FIELD_TYPE_DECIMAL:
case FIELD_TYPE_FLOAT:
- - --- 257,275 ----
}
else {
char *theData =3D =
calloc(sizeof(char),theLengths[i]+1);
+ char *theUselLess;
memcpy(theData, theRow[i],theLengths[i]);
theData[theLengths[i]] =3D '\0';
switch (theField[i].type) {
case FIELD_TYPE_TINY:
case FIELD_TYPE_SHORT:
case FIELD_TYPE_INT24:
+ case FIELD_TYPE_LONG:
+ theCurrentObj =3D =
[NSNumber numberWithLong:atol(theData)];
+ break;
case FIELD_TYPE_LONGLONG:
! theCurrentObj =3D [NSNumber=20
numberWithLongLong:strtoq(theData, &theUselLess, 0)];
break;
case FIELD_TYPE_DECIMAL:
case FIELD_TYPE_FLOAT:
Le mercredi, 20 ao=FB 2003, =E0 22:18 Europe/Amsterdam, Lorenz Textor a=20=
=E9crit :
> Hi Serge,
>
> Thank you for your quick answer!
>
> I'm using an old version, but I have checked the current version and=20=
> it seems to use the same method to get the numeric values.
>
> The field is of type BigInt and not unsigned, and the value is showed=20=
> correctly in other tools. If I open the table in my app, it shows=20
> always 2147483647 for values greater than this. I've tested it also=20
> with your MySQL Display app to be sure that it it is not an error of=20=
> my app - with the same result.
>
> Please tell me if I should test it with the newest version of the=20
> framework too! It's not that important, so look at it only if you have=20=
> the time... I'll also look at it, but I don't understand enough of=20
> this things (can it be a problem of the method numberWithLong: ?).
>
> Thanks very much for your work on the framework, it's really great!
> Cheers,
> Lorenz
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE/RKNB5EPeG5y7WPsRAi1iAJ980/xBi3PiJajwPaLJwBDMeSwXggCdEhPk
BHkmv05uMQ5w9/VCIOTODV0=3D
=3DhSlo
-----END PGP SIGNATURE-----
|