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