Je poursuis cette question sur les valeurs étranges dans une PERSISTED
colonne calculée. La réponse ici fait quelques suppositions sur la façon dont ce comportement est devenu.
Je pose la question suivante: n'est-ce pas un bug pur et simple? Les PERSISTED
colonnes peuvent-elles toujours se comporter de cette façon?
DECLARE @test TABLE (
Col1 INT,
Contains2 AS CASE WHEN 2 IN (Col1) THEN 1 ELSE 0 END PERSISTED) --depends on Col1
INSERT INTO @test (Col1) VALUES
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5)),
(ABS(CHECKSUM(NEWID()) % 5))
SELECT * FROM @test --shows impossible data
UPDATE @test SET Col1 = Col1*1 --"fix" the data by rewriting it
SELECT * FROM @test --observe fixed data
/*
Col1 Contains2
2 0
2 0
0 1
4 0
3 0
Col1 Contains2
2 1
2 1
0 0
4 0
3 0
*/
Notez que les données apparaissent "impossibles" car les valeurs de la colonne calculée ne correspondent pas à sa définition.
Il est bien connu que les fonctions non déterministes dans les requêtes peuvent se comporter étrangement, mais ici cela semble violer le contrat des colonnes calculées persistantes et, par conséquent, devrait être illégal.
L'insertion de nombres aléatoires pourrait être un scénario artificiel, mais que se passerait-il si nous insérions des NEWID()
valeurs ou SYSUTCDATETIME()
? Je pense que c'est une question pertinente qui pourrait pratiquement se manifester.