List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:September 16 1999 11:28pm
Subject:Re: Inserts wrong value into BIGINT UNSIGNED
View as plain text  
>>>>> "Rick" == Rick Moore <lrmoore@stripped> writes:

Rick> Monty-
Rick> I was trying to generate hash values for key ids, but I've switched back to
Rick> auto_increment because of all the problems I was running in to.

Rick> Problem #1:
Rick> This looked like a rounding error.  They were hash values, and I was
Rick> automatically masking out bit 63.  The field was declared "bigint unsigned
Rick> not null".

Rick> The number inserted was 3343683159361401134, and when I read it back the
Rick> rightmost 4 digits were a little messed up.  Strangely, it appeared
Rick> correctly in the database using mysql client under NT (3.22), but my app
Rick> using the C libs (also under NT) got an incorrect number.  Using the
Rick> debugger, I checked into the MYSQL_RES structure, and it was incorrect
Rick> there, too.

MySQL will return an bigint as a string both to 'mysql' and to any
application that use the C lib.  I can't think of any reason how this
could happens.  When you checked the MYSQL_RES structure, was the
number stored there as a string ?

Rick> Problem #2:
Rick> I don't think this is a mysql issue, but I don't really understand where the
Rick> issue lies.  Perhaps you can shed some light, or at least be aware that
Rick> someone else might bump into it and call it a MySQL bug.

Rick> My C code looks like this:
Rick>     sscanf(  row[ 0 ], "%I64u", &id );
Rick>     sscanf(  row[ 1 ], "%I64u", &answer );

Rick> Both very small numbers (<50), "answer" was correct and "id" wasn't (was
Rick> some ridiculously large number).  row[ 0 ] and row[ 1 ] both appeared to be
Rick> correct.  I'd like to blame MS library, but I use the same technique all
Rick> over the place in my code and it works fine everywhere else.  Very strange.

Rick> Regards,
Rick> Rick

Looks weird.  I assume both id and answer are declared as 64 bit integers.
Sorry, I can't explain this in any other way than to suggest that this 
may be stack related.  Did you check that the address of row[0] and
row[1] appeared to be legal ?

Regards,
Monty
Thread
Inserts wrong value into BIGINT UNSIGNEDUser Rick13 Sep
  • RE: Inserts wrong value into BIGINT UNSIGNEDBob Kline13 Sep
    • Re: Inserts wrong value into BIGINT UNSIGNEDRick Moore13 Sep
  • Inserts wrong value into BIGINT UNSIGNEDMichael Widenius16 Sep
  • Re: Inserts wrong value into BIGINT UNSIGNEDRick Moore16 Sep
    • Re: Inserts wrong value into BIGINT UNSIGNEDMichael Widenius16 Sep
  • Re: Inserts wrong value into BIGINT UNSIGNEDRick Moore16 Sep
    • Re: Inserts wrong value into BIGINT UNSIGNEDMichael Widenius17 Sep
  • Re: Inserts wrong value into BIGINT UNSIGNEDRick Moore17 Sep