Opened 17 years ago
Closed 17 years ago
#36 closed Bug (Fixed)
MS SQL BigInt masked with 0xFFFFFF00
Reported by: | jpoulsen2 | Owned by: | Valik |
---|---|---|---|
Milestone: | 3.2.11.1 | Component: | AutoIt |
Version: | 3.2.10.0 | Severity: | |
Keywords: | Cc: |
Description (last modified by Jpm)
When storing an integet value as a bigint, decimal or numeric in MS SQL db using ADODB, the value is stored correctly in the db (verified with DatAdmin 0.8.8). But when the value is returned it seems to be masked with 0xFFFFFF00 resulting in the last byte always being 0. This problem does not occur with the types float and int.
Sample code: see attached file
Attachments (1)
Change History (9)
comment:1 Changed 17 years ago by anonymous
Changed 17 years ago by Jpm
comment:2 Changed 17 years ago by Jpm
- Description modified (diff)
comment:3 follow-up: ↓ 4 Changed 17 years ago by AutoIt User
The same happens to me using _FileReadToArray / _FileWriteFromArray.
Version: 3.2.10.0
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 17 years ago by Jpm
Replying to AutoIt User:
The same happens to me using _FileReadToArray / _FileWriteFromArray.
Version: 3.2.10.0
are you sure to speak about the ticket subject?
There is no relation between SQLite and those UDF's
comment:5 in reply to: ↑ 4 Changed 17 years ago by AutoIt User
Replying to Jpm:
Replying to AutoIt User:
The same happens to me using _FileReadToArray / _FileWriteFromArray.
Version: 3.2.10.0
are you sure to speak about the ticket subject?
There is no relation between SQLite and those UDF's
It's not releated to ticket subject. Just have similar problems using _FileReadToArray / _FileWriteFromArray. If the first array value was an hexed string (e.g. 0xFFFFFFFFFFF) while saving, the result by reading back was 0 or scrambled data. This behavior seems to be fixed in the 3.2.11 beta, this won't happend anymore.
comment:6 Changed 17 years ago by Valik
- Owner set to Valik
- Status changed from new to accepted
comment:7 Changed 17 years ago by Valik
I can confirm everything that's been said by the reporter. I've finally figured out how to get the example script working. I get the same results as the OP and I also verified that the data is stored in the database correctly. The next step is to do some quick debugging to see what the data looks like when it comes in to AutoIt.
comment:8 Changed 17 years ago by Valik
- Milestone set to 3.2.11.1
- Resolution set to fixed
- Status changed from accepted to closed
Fixed in version: 3.2.11.1
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
And here is the output from running the script against my MS SQL Server 2005
CREATE TABLE int_test(ip_addr1 float, ip_addr2 int, ip_addr3 bigint, ip_addr4 decimal(12), ip_addr5 numeric(12))
INSERT INTO int_test VALUES(-1407448780,-1407448780,-1407448780,-1407448780,-1407448780)
INSERT INTO int_test VALUES(1104350679,1104350679,1104350679,1104350679,1104350679)
INSERT INTO int_test VALUES(2130706434,2130706434,2130706434,2130706434,2130706434)
SELECT * FROM int_test
0: -1407448780 - AC1C0934
1: -1407448780 - AC1C0934
2: -1407448832 - AC1C0900
3: -1407448832 - AC1C0900
4: -1407448832 - AC1C0900
0: 1104350679 - 41D30DD7
1: 1104350679 - 41D30DD7
2: 1104350720 - 41D30E00
3: 1104350720 - 41D30E00
4: 1104350720 - 41D30E00
0: 2130706434 - 7F000002
1: 2130706434 - 7F000002
2: 2130706432 - 7F000000
3: 2130706432 - 7F000000
4: 2130706432 - 7F000000