none
[SSRS - SQL SEVER 2008 R2] - Problème de syntaxe des requêtes paramétrées RRS feed

  • Question

  •  Hello,

    J'ai un problème pour paramétrer des requêtes sur SSRS. J'entends paramétrer c'est-à-dire d'utiliser une variable dans le <CommandText>.

    Je vais prendre l'exemple d'une qui ne marche pas.

    = "

    begin try

    use [

    " & Parameters!DatabaseName.Value & "] ;

    declare @table_name varchar(500) ;

    declare @schema_name varchar(500) ;

    declare @tab1 table(

    tablename varchar (500) collate database_default

    , schemaname varchar(500) collate database_default

    );

    declare @temp_table table (

    tablename sysname

    , row_count int

    , reserved varchar(50) collate database_default

    , data varchar(50) collate database_default

    , index_size varchar(50) collate database_default

    , unused varchar(50) collate database_default

    );

    insert into @tab1

    select t1.name

    , t2.name

    from sys.tables t1

    inner join sys.schemas t2 on ( t1.schema_id = t2.schema_id );

    declare c1 cursor

    for

    select t2.name + '.' + t1.name

    from sys.tables t1

    inner join sys.schemas t2 on ( t1.schema_id = t2.schema_id );

    open c1;

    fetch NEXT from c1 into @table_name;

    while @@FETCH_STATUS = 0

    begin

    set @table_name = replace(@table_name,

    '[','');

    set @table_name = replace(@table_name, ']','');

    -- make sure the object exists before calling sp_spacedused

    if exists(SELECT object_id FROM sys.objects WHERE object_id = object_id(@table_name))

    begin

    insert into @temp_table exec sp_spaceused @table_name, false ;

    end

     

    fetch NEXT from c1 into @table_name;

    end;

    close c1;

    deallocate c1;

    select (row_number() over(order by t2.schemaname,t2.tablename))%2 as l1

    , t1.*

    , t2.schemaname

    from @temp_table t1

    inner join @tab1 t2 on (t1.tablename = t2.tablename )

    order by schemaname,tablename;

    end try

    begin catch

    select -100 as l1

    , ERROR_NUMBER() as tablename

    , ERROR_SEVERITY() as row_count

    , ERROR_STATE() as reserved

    , ERROR_MESSAGE() as data

    , 1 as index_size, 1 as unused, 1 as schemaname

    e

     

    nd catch

    "

    Vous l'aurez sans doute reconnu, cette requête permet de récupérer l'espace occupé pour chaque table d'une base de données.

    Sur des requêtes plus simple, notamment celle contenant une clause WHERE, le simple fait de passer la requête en string (="") empêche la bonne exécution.

    Quelqu'un aurait-il une idée ?

    Cordialement, Arnaud.

    lundi 31 janvier 2011 13:32

Réponses

  • A vrai dire, j'ai contourné le problème.

    Mon objectif était de variabiliser la base de données vers laquelle j'éxécutais la requête.

    N'ayant pas réussi à le faire via USE @PARAMETER, j'ai finalement décidé de variabiliser la connection string de la DataSource en utilisant une expression.

    Cordialement, Arnaud.

    • Marqué comme réponse Alex Petrescu lundi 7 février 2011 11:19
    lundi 7 février 2011 09:27

Toutes les réponses

  • Bonjour,

     

    Essayez d’analyser la requête générée avec Query Analyzer pour identifier les erreurs. Je vous propose d’utiliser une requête plus simple et de nous montrer le message d’erreur que vous recevrez.

     

    Cordialement,

    Alex

    ________________

    Publiez un article sur MSDN !

    Windows Phone 7

    Astuces pour Visual Studio 2010

    XNA – Développement jeux vidéo

    Didacticiels et astuces : VB.NET, C#, ASP.NET, .NET Framework, Silverlight, Workflow Foundation, SharePoint, WPF

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

     

     


    Suivez MSDN sur Twitter 

    mardi 1 février 2011 15:18
  •  En fait, je me trouve confronté à 2 problèmes :

    Voici un exemple en partant d'une requête très simple :

    select T.A
    from (select 1 as A) T
    where 1=1

    En mettant cette requête dans le DataSet, je n'ai aucun problème.

    Mon objectif est de rendre dynamique cette requête. Je veux la paramétrer soit en construisant moi-même ma chaine de caractère, soit en utilisant un paramètre.

     Cependant, je trouve une erreur d'interprétation de la requête si j'écris l'expression ci-dessous dans un DataSet : 

    ="select T.A
    from (select 1 as A) T
    where 1=1"

    De la même manière, je tombe sur une erreur quand j'utilise un paramètre (préalablement définit dans l'onglet Parameter du DataSet):

    select T.A
    from (select 1 as A) T
    where @A=1

    L'erreur dans ce cas est :

    Query execution failed for dataset 'DataSet1'

    Must declare the scalar variable "@A".

    Je voudrais bien savoir quelle est la syntaxe correct dans les deux cas afin de pouvoir paramétrer une requête.

    Par avance, merci.

    mercredi 2 février 2011 09:33
  • Bonjour,

     

    Je vous propose le didacticiel MSDN pour l’utilisation des paramètres dans un rapport :

     

    Ajout de paramètres a un rapport (SSRS)

     

    Cordialement,

    Alex

    ________________

    Publiez un article sur MSDN !

    Windows Phone 7

    Astuces pour Visual Studio 2010

    XNA – Développement jeux vidéo

    Didacticiels et astuces : VB.NET, C#, ASP.NET, .NET Framework, Silverlight, Workflow Foundation, SharePoint, WPF

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

     

     


    Suivez MSDN sur Twitter 

    mercredi 2 février 2011 12:43
  • Bonjour,

    Alors je réponds peut-être à coté de la plaque, mais sait-on jamais, comme j'ai vu que ça parlait de Dataset, cela pourrait être utile ...

    Si ta requête doit forcément écrite au vol, et nécessite plus qu'un passage de paramètres, dans ce cas il te faut surcharger ton DataTableAdapter pour pouvoir faire un Set d'une des requêtes du DataTableAdapter.

    Cela se fait en écrivant une classe partielle.

    Pour ce faire, il te faut rendre ton SelectCommand (par exemple) éditable.

    Tu fais clic droit sur ton Dataset, Voir le Code, et à l'intérieur, tu rajoutes :

    namespace myDataSetTableAdapters
    {
     partial class myTableAdapter
     {
     public System.Data.SqlClient.SqlCommand getSelectCommand() {
     return this.CommandCollection(0);
     }
     }
    }

    Une fois que c'est fait, il te suffit de faire :

    myTableAdapter.getSelectCommand().CommandText="SELECT * FROM table WHERE truc='machin'";

    Plus d'infos à ce sujet-là sur ce thread .

    Cordialement,

    Thomas

     


    Thomas Aimonetti - C# - Sharplog Engineering - http://www.sharplog.fr
    mercredi 2 février 2011 12:52
  • Bonjour,

     

    Arnaud, est-ce que ces informations vous ont été utiles ? Pouvez-vous nous dire quel est l’état de votre projet dans ce moment ?

     

    Cordialement,

    Alex

    ________________

    Publiez un article sur MSDN !

    Windows Phone 7

    Astuces pour Visual Studio 2010

    XNA – Développement jeux vidéo

    Didacticiels et astuces : VB.NET, C#, ASP.NET, .NET Framework, Silverlight, Workflow Foundation, SharePoint, WPF

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

     

     


    Suivez MSDN sur Twitter 

    vendredi 4 février 2011 10:10
  • A vrai dire, j'ai contourné le problème.

    Mon objectif était de variabiliser la base de données vers laquelle j'éxécutais la requête.

    N'ayant pas réussi à le faire via USE @PARAMETER, j'ai finalement décidé de variabiliser la connection string de la DataSource en utilisant une expression.

    Cordialement, Arnaud.

    • Marqué comme réponse Alex Petrescu lundi 7 février 2011 11:19
    lundi 7 février 2011 09:27