Insertion de «null» (littéralement) dans un paramètre de procédure stockée

Question

J'essaie d'insérer le mot «null» (littéralement) dans un paramètre pour une procédure stockée. Pour une raison quelconque, SqlServer semble penser que je veux dire NULL et non "Null". Si je fais une vérification pour

IF @LastName IS NULL // Test: Do stuff 

Ensuite, il contourne cela parce que le paramètre n'est pas nul.

Mais quand je fais:

INSERT INTO Person (<params>) VALUES (<stuff here>, @LastName, <more stuff here>); // LastName is 'Null' 

bombes Il en disant que LastName n'accepte pas les valeurs NULL. Je détesterais sérieusement avoir ce nom de famille, mais quelqu'un le fait ... et il bombarde l'application. Nous utilisons SubSonic 2.0 (ouais, c'est assez vieux mais la mise à jour est douloureuse) comme notre DAL et en passant par là, je vois que ça crée les paramètres correctement (pour ce que je peux dire).

J'ai essayé de créer une table temporaire pour voir si je pouvais la répliquer manuellement, mais cela semble fonctionner correctement. Voici l'exemple que je crée:

DECLARE @myval VARCHAR(50) 
SET @myval = 'Null' 
CREATE TABLE #mytable(name VARCHAR(50)) 
INSERT INTO #mytable VALUES (@myval) 
SELECT * FROM #mytable 
DROP table #mytable 

Toute réflexion sur la façon dont je peux résoudre ce problème?

edit: La méthode que le nom de famille est définie est this - myPerson.LastName = textBoxLastName.Text;

edit: Lors de l'utilisation de SqlServer Profiler, je vois qu'il envoie null. Deux choses bizarres, je me demande pourquoi mon "IF @lastName IS NULL" ne tire pas ... mais maintenant je dois regarder SubSonic plus loin pour voir si quelque chose change à la dernière minute dont je n'étais pas conscient. Je vais enquêter plus loin et faire un rapport.

edit: La seule contrainte est une valeur par défaut de ''.

edit: Ok, j'ai confirmé que c'est IS SubSonic essayant de jouer intelligemment. Bonne idée pour utiliser le Profiler, j'ai complètement oublié cela. Dernière modification: Il est intéressant de noter, à l'avenir, que SubSonic remplace cela à la dernière minute dans le fournisseur de données (dans mon cas SqlDataProvider). Dans le DataService.cs où il appelle Execute Scalar, les paramètres n'ont pas encore été ajustés. Ils sont ajustés quand il exécute ExecuteScalar pour le DataProvider, qui est une classe abstraite (donc Postgre et Oracle auront chacun leurs propres bits de code). Plus précisément, le SubSonic.SqlDataProvider.AddParams est ce qui m'a mordu.

Answer 1

Il convient de noter, référence future de la fourrure, qui SubSonic remplace à la dernière minute dans le fournisseur de données (dans mon cas SqlDataProvider). Dans le DataService.cs où il appelle Execute Scalar, les paramètres n'ont pas encore été ajustés.Ils sont ajustés quand il exécute ExecuteScalar pour le DataProvider, qui est une classe abstraite (donc Postgre et Oracle auront chacun leurs propres bits de code). Plus précisément, le SubSonic.SqlDataProvider.AddParams est ce qui m'a mordu.

Answer 2

S'il vous plaît essayez ceci:

Oups ... Je suis totalement mal compris la question. Je pense qu'il devrait y avoir certaines contraintes définies dans la colonne de la base de données. S'il vous plaît essayez d'écrire la requête d'insertion directement dans DB et voir si elle bombarde.

J'ai essayé et il bombes comme prévu:

DECLARE @myval VARCHAR(50) 
SET @myval = 'null' 
CREATE TABLE #mytable(name VARCHAR(50) NULL CHECK (name <> 'NULL')) 
INSERT INTO #mytable VALUES (@myval) 
SELECT * FROM #mytable WHERE name is not null 
DROP table #mytable 

HTH