Gestion hexadécimale SQL Server

Question

Je crois que j'ai un problème avec la façon dont SQL Server 2000 gère les nombres hexadécimaux.

Si je fais un

select * from table where [timestamp] = 44731446 

la ligne qui retourne montre l'horodatage comme 0x0000000202AA8C36

même dans une autre table si je

select * from table2 where [timestamp] = 44731446 

la ligne qui retourne montre l'horodatage comme 0x0000000002AA8C36 (notez le 2 manquant)

MS Calc me dit que le premier timestamp = 8634666038 en décimal et le second timestamp = 44731446 en décimal qui correspond à ma requête d'origine sur les deux tables.

Alors pourquoi SQL Server renvoie-t-il un nombre différent, mais l'interroge avec succès? Je crois que c'est la route d'un problème de mise à jour que j'ai où la rangée ne mettra pas à jour.

Answer 1

Longue histoire courte, la conversion binaire en entier tronque données:

select cast(0x0000000202AA8C36 as int) 

Une colonne TIMESTAMP est vraiment BINARY (8), de sorte que votre requête compare une valeur BINARY (8) à une valeur INT; parce que INT a la plus haute priorité, MSSQL convertit la valeur BINARY (8) en INT avant de les comparer. Mais 0x0000000202AA8C36 (ou 8634666038) est trop grand pour être représenté comme INT, donc MSSQL doit le tronquer en premier, et il tronque à la même valeur que 0x0000000002AA8C36. Cela pourrait être un peu plus clair:

create table dbo.t (tstamp binary(8) not null) 
go 

insert into dbo.t values (0x0000000202AA8C36) 
insert into dbo.t values (0x0000000002AA8C36) 
go 

-- returns 2 rows 
select * from dbo.t where tstamp = 44731446 
-- returns 1 row 
select * from dbo.t where tstamp = cast(44731446 as bigint) 
go 

drop table dbo.t 
go 

Selon Livres en ligne (pour 2008, je n'ai pas 2000):

Lorsque [types de données non-string] sont convertis en binaire ou varbinary, les données sont rembourrées ou tronquées sur la gauche. Le remplissage est effectué à l'aide de zéros hexadécimaux