51372 and -14163 have the same lower 16 bits
so my question would be… what is the mySQL datatype for ID?
if it is a 16bit Integer than that would explain it. as the maximum POSTIVE value would be 32767 (51372 overflows and rolls over to -14163
It all depends on what Xojo does to convert a SMALLINT from mySQL to an INTEGER via the database interface.
Since Database field doesn’t have the equivalent of UINT16 it ends up a INT32
and if you take the 16bits of -14163 and map them into a 32bit space, you end up with a POSITIVE number
the most significant bit indicates SIGN… the most significant bit of a UINT16 is bit #15, but it is bit#31 in an INT32
so none of this suprised me in the slightest.
1100 1000 1010 1100 = 0xC8AC as a 16bit number, but it is 0x0000C8AC as a 32bit number, drastically changing the “meaning” of that first bit
But it’s crazy to change all columns i have set to small int to int because this problem.
I have about 97 tables with at least 1 small int column per table and indexes also.
I do not want to modify mysql structure
And i reported another problem like this on 21 Oct 2015
“41294 - Using DownTo with a For loop is buggy with unsigned loop counters”
[i]
dim i as UInt8 // or Uint16
for i=2 downto 0
i=i
next
Expected Result: do not enter anymore after i=0
Actual Result: enter after i=0
Workarounds: need to put an “if i=0 then exit”[/i]
And who has said it wasn’t be considered? You filed the feedback less than a month ago… it may be a year or more before it makes it into a production release… if then.
Your expecting 0 not to be included.
But Down to 0 does define 0 to be included, in english (correct me if im wrong). I expect down to the last detail to do the same, but not to leave the last detail.
Perhaps you should change your code to DownTo 1 (is inclusive)
Also your expected result says:
Do not enter any more after i=0