Serveur SQL. Pourquoi la valeur du champ de n'importe quel type peut être traitée comme une string entre guillemets dans Query / DML?

J'ai découvert SUDDENLY que dans SQL Server (2000) toute valeur de type de champ peut être traitée comme une string entre guillemets (en requête ou DML).

Question: Est-ce un comportement normal ou un résultat accidentellement réussi?

Example: CREATE TABLE [Test_table] ( [int_field] [int] NULL , [float_field] [float] NULL , [date_field] [datetime] NULL , [id] [int] NOT NULL ) ON [PRIMARY] GO update test_table set int_field = 100, float_field = 10.01, date_field = CAST('2013-11-10' AS DATETIME) where id = 1 update test_table set int_field = '200', float_field = '20.02', date_field = '2014-12-10' where id = '2' select * from test_table where id in ('1', 2) -- WHY '1' DOES WORK!???

Pourquoi j'ai besoin de ça? Il existe une idée pour envoyer une procédure stockée sur 270 parameters comme text intégral (XML ou serialization personnalisée par des délimiteurs ou comme Len1 + value1 + len2 + value2 + ..) puis parsingr et extraire toutes les valeurs désirées et les utiliser dans l'instruction UPDATE . Cette question SO .

Q2: Y a-t-il des limitations pour certains types? Q3: Cette méthode fiable ou CAST est-elle recommandée?

Si vous consultez la rubrique CAST et CONVERT , vous findez une table pratique:

entrez la description de l'image ici

Vous remarquerez que la conversion de char et varchar est prise en charge pour tous les autres types, et seulement quelques-uns d'entre eux nécessitent des conversions explicites. Pour certains types, il n'y a aucun moyen évident de taper un littéral de ce type, donc autoriser les conversions implicites à partir d'une string est logique.

(Mais oh, comment je souhaite que la conversion en datetime nécessite un cas explicite avec un code de format …)

SQL Server, comme la plupart des marques de SQL, tente automatiquement de faire passer les choses au bon type. C'est un comportement assez standard.

Il devrait être fiable dans les cas ci-dessus. Dans les instructions update et select , le type à convertir est connu (à partir des définitions de colonnes des tables).

Cependant, le moulage automatique peut introduire des problèmes subtils quand il fait partie d'une requête plus complexe. Certains types de SQL auront des problèmes avec des instructions comme celle-ci:

 select case when foo=1 then 0 else 'a' end from table

Dans ce cas, le type de résultat ne sera pas forcément quelque chose qui peut accepter tous les types de résultats, donc il pourrait échouer quand il essaye d'assigner 'a'. Soyez prudent lorsque vous utilisez la conversion automatique dans les instructions complexes. Il est probablement préférable de le rendre explicite dans de tels cas.

Un autre problème potentiel lié à la transmission de toutes les strings sous la forme de strings est qu'une erreur se produira si vous transmettez accidentellement une valeur non numérique.