mysql-cocoa-users

[Mysql-cocoa-users] =?ISO-8859-1?Q?R=E9p_:_[Mysql-cocoa-users]_Bug_with_BigInt_data_?= =?ISO-8859-1?Q?types?=

[Serge C. <ser...@us...>]

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

[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...