[Mysql-cocoa-users] =?ISO-8859-1?Q?Re:_R=E9p_:_[Mysql-cocoa-users]_Bug_with_BigInt_d?= =?ISO-8859-1?Q?ata_types?=

[Lorenz T. <lo...@te...>]

Hi Serge,
>
> I've fixed the BIGINT issue.
Thanks so much for fixing it so fast!

> 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=20
> corrected 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.
Unfortunately I'm still having v1, because I'm using only the basic=20
features of the framework and I am sure that by now everything works=20
fine (I don't have the time by now for testing CocoaMySQL to be sure it=20=

works with the new framework).
I can download the source from CVS, thanks. Or I take the changes from=20=

the code attached at the end of the email (these are all changes=20
necesary, right?).

By the way, I have added some lines to the fetchRow methods which fixes=20=

problems with:
- timestamps other than default representation
- dates in formats like 0000-00-00 (which gives an error when trying to=20=

initialize a cocoa date object with a "null"-date)
If you want the diffs, just tell me!

>
> 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=20
> the end only strtoq can do what we wanted.
Thanks again for fixing that. I have not much experience with C, so it=20=

would take me much time to solve such a problem...

> PPS: I'll try to check if their is a way to know if the field=20
> retrieved is unsigned, in which case I will adapt the code to also=20
> handle the unsigned int and bigint. If someone knows how to do that...=20=

> please spear me the search by myself (enlighten me... :-).
Can't you use the C API function mysql_fetch_fields() to get the=20
MYSQL_FIELD structure and then check if the flag UNSIGNED_FLAG is set?

Best Regards,
Lorenz

>
> 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=20
>> have the time... I'll also look at it, but I don't understand enough=20=

>> of 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-----
>
>
>

--=20
lorenz textor
** sh **
eigerstrasse 21
8200 schaffhausen
tf 052 - 624 27 91
** ticino **
via delle scuole 41
6963 pregassona
tf 091 - 940 20 57
**
mobile 076 - 531 71 74
email lo...@te...