Les sous-requêtes ne sont pas autorisés dans ce contexte. Seulement les expressions scalaires sont autorisés

Ma procédure stockée fonctionne très bien dans SQL Server 2008, mais lorsque j'essaie d'exécuter la même procédure dans SQL server 2005, il met cette erreur indiquant

Les sous-requêtes ne sont pas autorisés dans ce contexte. Seulement les expressions scalaires sont autorisés.

qui suit est ma sp

USE dbEmployeeManagementSystem
GO
CREATE PROCEDURE [dbo].spInsertTaskAssignmentsample
(
@Username nvarchar(50),
@ProjectName nvarchar(50),
@ClientName nvarchar(50),
@Status nvarchar(50),
@StartDate nvarchar(50),
@EndDate nvarchar(50),
@ReportingManager nvarchar(50),
@Comments nvarchar(100)
 )
AS
BEGIN   
INSERT INTO tblTaskAssignment
(EID,ProjectName, ClientName, Status, StartDate, EndDate,ReportingManager,Comments) 
Values
((SELECT top 1 EID FROM tblLogin WHERE Username=@Username), @ProjectName, @ClientName, @Status, @StartDate, @EndDate,@ReportingManager,@Comments)
END

S'il vous plaît aidez-moi, est-il une solution pour ce ou de sql 2005 fais de soutenir ce genre de questions?

Merci d'avance.

Utilisation INSERT INTO ... SELECT

OriginalL'auteur user2470174 | 2013-06-12

  1. 10

    Vous pouvez utiliser SELECT au lieu d'un VALUES clause:

    INSERT INTO tblTaskAssignment
(EID,ProjectName, ClientName, Status, StartDate, EndDate,ReportingManager,Comments) 
SELECT (SELECT TOP 1 EID FROM tblLogin WHERE Username=@Username), @ProjectName, @ClientName, @Status, @StartDate, @EndDate,@ReportingManager,@Comments

    OriginalL'auteur ta.speot.is

  2. 4

    SQL Server 2005 ne prend pas en charge cette. Il a été introduit en 2008.

    Vous pouvez affecter le résultat de la sous-requête pour une variable à la place et de l'utiliser dans le VALUES clause.

    L'affectation à une variable semble exagéré. N'2005 pas en charge INSERT INTO ... SELECT?
    Il n'mais si la sous-requête renvoie 0 lignes qui est plus délicat. Il faut insérer NULL.
    La variable et la sous-requête sera de retour NULL de toute façon? INSERT INTO ... SELECT (subquery), @v1, @v2
    Ah voir ce que tu veux dire. Je pensais que vous parliez de INSERT ... SELECT top 1 EID, @ProjectName, @ClientName FROM tblLogin WHERE Username=@Username
    Eh bien, je ne dirais pas une variable, c'est du matraquage...C'est juste deux façons de faire le travail. Je ne dirais pas que les différences sont que les grands 🙂

    OriginalL'auteur Martin Smith

  3. 2

    Variante 1:

    Vous pouvez mettre de l'AÏD dans une variable comme ceci:

        CREATE PROCEDURE [dbo].spInsertTaskAssignmentsample
    (
    @Username nvarchar(50),
    @ProjectName nvarchar(50),
    @ClientName nvarchar(50),
    @Status nvarchar(50),
    @StartDate nvarchar(50),
    @EndDate nvarchar(50),
    @ReportingManager nvarchar(50),
    @Comments nvarchar(100)
     )
    AS
    BEGIN

    DECLARE @EID INT;
    SET @EID = (SELECT top 1 EID FROM tblLogin WHERE Username=@Username);

    INSERT INTO tblTaskAssignment
    (EID,ProjectName, ClientName, Status, StartDate, EndDate,ReportingManager,Comments) 
    Values
    (@EID, @ProjectName, @ClientName, @Status, @StartDate, @EndDate,@ReportingManager,@Comments)
    END

    Si EID n'est pas de type entier, vous aurez à spécifier que le type dans l'instruction declare

    Variante 2:
    L'utilisation d'une clause SELECT

        CREATE PROCEDURE [dbo].spInsertTaskAssignmentsample
    (
    @Username nvarchar(50),
    @ProjectName nvarchar(50),
    @ClientName nvarchar(50),
    @Status nvarchar(50),
    @StartDate nvarchar(50),
    @EndDate nvarchar(50),
    @ReportingManager nvarchar(50),
    @Comments nvarchar(100)
     )
    AS
    BEGIN

    INSERT INTO tblTaskAssignment
    (EID,ProjectName, ClientName, Status, StartDate, EndDate,ReportingManager,Comments) 
    SELECT TOP 1 EID, @ProjectName, @ClientName, @Status, @StartDate, @EndDate,@ReportingManager,@Comments FROM tblLogin WHERE Username=@Username 
    END
    La variante 2 peut échouer si il n'y a pas d'utilisateur avec @Username dans le tblLogin table, mais qui ne sera un problème si la procédure stockée est de s'attendre à ce qu'un "manque" @username peut être saisie

    OriginalL'auteur mortb

  4. 0

    Vous pouvez utiliser SELECT au lieu d'un VALUES clause:

    INSERT INTO tblTaskAssignment
(EID,ProjectName, ClientName, Status, StartDate, EndDate,
    ReportingManager,Comments) 
SELECT top 1 EID, @ProjectName, @ClientName, @Status, @StartDate, @EndDate,
    @ReportingManager,@Comments
FROM tblLogin WHERE Username=@Username

    (À noter toutefois, que par la discussion entre Martin Smith et ta.speot.est, cela ne présume qu'il y aura au moins une ligne de tblLogin qui correspond à @Username)

    -1 résultat différent si aucune ligne n'est renvoyée.
    J'étais juste en ajoutant que comme une hypothèse - que nous ne savons pas si la coopérative doit faire face à cet aspect ou pas (peut-être à l'origine de la requête tombe même sur 2008 dans une telle circonstance, parce que EID n'est pas nullable)
    Ou écrivez le INSERT INTO ... SELECT d'une manière qui ne fait pas l'hypothèse.
    le point est, vous êtes en supposant que NULL est une valeur valide ici, et un résultat souhaitable.
    L'OP suppose que trop, dans le contexte de leurs question je suis ne pas croire n'importe quoi.

    OriginalL'auteur Damien_The_Unbeliever