2009-09-03 8 views
0

Ma procédure fonctionnait correctement dans une base de données de 2005, mais mon PC est mort et lorsque j'ai recommencé, j'ai installé 2008 plutôt que 2005 - maintenant cette procédure ne renvoie aucun résultat. Je pose la question sur la différence entre les 2 versions simplement parce que j'ai utilisé cette logique auparavant et je n'ai pas changé la procédure depuis que je l'ai créé et ça fonctionnait, le seul changement a été le fait que j'utilise maintenant SQL 2008Pourquoi SQL2008 n'interprète-t-il pas la clause WHERE conditionnelle dans ma procédure stockée de la même manière qu'en 2005?

J'ai écrit la procédure dans Visual Studio et j'ai remarqué que lorsque je colle l'instruction select dans le volet SQL pour la table, elle est restructurée et développée afin que chaque variation puisse être exprimée en combinant les ANDs et ORs.

Ce dont j'ai besoin, c'est de pouvoir appeler cette procédure en passant l'un ou l'autre paramètre; donc si je ne passe que le componentType, il devrait évaluer la partie déclaration finale de l'instruction et utiliser la valeur transmise - si aucune valeur n'a été transmise, elle correspondrait au côté IS NULL de la condition.

ALTER PROCEDURE dbo.uspSel_ComponentByType(
    @filterText  VARCHAR(50) = NULL 
, @componentType CHAR(2)  = NULL) 
AS 
SELECT [pkComponentID], [ComponentType], [ComponentName], [fkSupplierID], [Cost], [WastageCost] 
FROM [tblComponents] AS c INNER JOIN 
     [tblSuppliers] AS s ON [c].[fkSupplierID] = [s].[pkSupplierID] 
WHERE ([ComponentName] LIKE @filterText + '%' OR [SupplierName] LIKE @filterText + '%') 
AND [c].[IsDeleted] = 0 
AND (@componentType IS NULL OR [ComponentType] = @componentType) 
+0

est le code affiché la procédure que vous l'avez écrit, ou le proc restructuré par Visual Studio? –

+0

Le code est tel que je l'ai écrit, Visual Studio (et SSMS) le restructurer et le présenter différemment. –

Répondre

1

Je ne suis pas pro SQL, mais si je comprends bien, vous devriez être en mesure vos intentions d'utiliser le sproc sans/soit/les deux paramètres et obtenir des résultats attendus en cas de défaut @filterText-'' au lieu de NULL .

ALTER PROCEDURE dbo.uspSel_ComponentByType(
    @filterText   VARCHAR(50)  = ''  , 
    @componentType  CHAR(2)   = NULL 
) 
AS 
    SELECT ... --the rest of the sproc is unchanged 

Comme David M a précisé, cela est probablement parce que SQL Server 2005 et 2008 gère concaténation de chaîne avec des valeurs NULL différemment. Il semble que dans SQL Server 2005

'A string' + NULL = 'A string'; 

alors que dans SQL Server 2008

'A string' + NULL = NULL; 

En changeant la valeur par défaut à '', nous avons fait la comparaison par défaut '' + '%', qui sera toujours traité comme % et correspondre à tout , au lieu de NULL + '%', qui se terminera par NULL et ne correspondra à rien.

+0

Battez-moi en quelques secondes ...;) –

+1

'Une chaîne' + NULL = NULL dans SQL Server 2005. SET CONCAT_NULL_YIELDS_NULL: http://msdn.microsoft.com/en-us/library/ms176056(SQL.90) .aspx – gbn

+0

... et il en a été ainsi depuis SQL Server 7. Ce qui s'est passé, ce sont les valeurs par défaut pour les connexions et les nouvelles bases de données ont changé d'une version à l'autre. – gbn

1

Cela ressemble à la gestion par défaut différente de la concaténation d'une valeur nulle - il concatène maintenant NULL avec '%' pour donner NULL, entraînant l'échec de la comparaison LIKE. Si vous remplacez le NULL par défaut avec une chaîne vide pour @filterText vous avez une procédure stockée qui n'est pas affectée par une telle différence de comportement.

+0

Merci pour l'explication David; penser en ce sens a du sens –

0

Je pense qu'il est dû à définir des options, en particulier est susceptible CONCAT_NULL_YIELDS_NULL, avec ANSI_NULLS comme barboteur

Questions connexes