How to insert Dynamic SQL in list and labels? - datasource

How to write a Dynamic SQL query with bind/substitute variables in List and Labels report server?
When creating the Datasource I have the option to enter the query manually, but as soon I enter the bind an error message is displayed.
I want to be able to enter a dynamic query in the datasource and set the value of that bind/substitution variable.

This is something that's actively being worked on. This blog post covers the basics for parametrized data sources within List & Label itself. Thorough support within the Report Server, including support for stored procedure parameters, is on the roadmap and will be released this fall.

Related

How to use a dynamic parameter with a command in crystal reports?

The problem I'm running into is quite easy to recreate.
In Crystal Reports Developer I add two different tables:
The full table "Users"
A Command containing SELECT * FROM Users
In the Field Explorer I add a new parameter and set this to dynamic. I have this parameter pull it's data from any field in either of the two tables (doesn't matter). Of course making sure the parameter is used in the record select.
If I now preview this report (in Developer) it works perfectly. I get a popup allowing me to select data from whatever field I selected in the parameter.
Using this report in Crystal Viewer it prompts for database username and password.
It seems it only does this when the same report contains both a dynamic parameter and a command. Removing the SQL command (leaving only the table) and the report works as expected.
Does anyone know how to resolve this, or is there some workaround?

Creating a custom "WHERE" filter in Excel SQL connection

I have easily created a custom SQL Query to populate an Excel from an SQL database.
This was quite straightforward and easy (Data/from External sources/Microsoft SQL - and then edited the command text section of the connection properties)
But now, I would like to use a WHERE clause with a parameter from a cell.
From what I read on every tutorials and similar SO questions, I should simply have to use a question mark and Excel will understand it and allow me to define a cell.
Sources:
How to add parameters to an external data query in Excel which can't be displayed graphically?
That's what I did:
Unfortunately I got this dialog telling me that some info are missing:
You should use Microsoft Query first , and then change the Command Text later.
Refer from this: Excel: Send multiple values in "Command text"

Allow Drop Downs in an SSRS Report (2008) to accept text as an input

Okay, so I have an SSRS report that has a parameter with available values from a query. All of this works fine, but I would like the user to be able to select multiple items using: "SomeText%" which will retrieve all like: SomeText12, SomeTextHeyThere etc. The sql for this is all set up, but once you set the parameter to get values from a query in visual studio, you don't have the option to enter in text as well. This seems like it should be a common feature. Does anyone know how to add it so that the user can enter text and select from the drop down at the same time? I can create 2 parameters to do this, but that is just clunky.
Thanks!

SQL Parameters - where does expansion happens

I'm getting a little confused about using parameters with SQL queries, and seeing some things that I can't immediately explain, so I'm just after some background info at this point.
First, is there a standard format for parameter names in queries, or is this database/middleware dependent ? I've seen both this:-
DELETE * FROM #tablename
and...
DELETE * FROM :tablename
Second - where (typically) does the parameter replacement happen? Are parameters replaced/expanded before the query is sent to the database, or does the database receive params and query separately, and perform the expansion itself?
Just as background, I'm using the DevArt UniDAC toolkit from a C++Builder app to connect via ODBC to an Excel spreadsheet. I know this is almost pessimal in a few ways... (I'm trying to understand why a particular command works only when it doesn't use parameters)
With such data access libraries, like UniDAC or FireDAC, you can use macros. They allow you to use special markers (called macro) in the places of a SQL command, where parameter are disallowed. I dont know UniDAC API, but will provide a sample for FireDAC:
ADQuery1.SQL.Text := 'DELETE * FROM &tablename';
ADQuery1.MacroByName('tablename').AsRaw := 'MyTab';
ADQuery1.ExecSQL;
Second - where (typically) does the parameter replacement happen?
It doesn't. That's the whole point. Data elements in your query stay data items. Code elements stay code elements. The two never intersect, and thus there is never an opportunity for malicious data to be treated as code.
connect via ODBC to an Excel spreadsheet... I'm trying to understand why a particular command works only when it doesn't use parameters
Excel isn't really a database engine, but if it were, you still can't use a parameter for the name a table.
SQL parameters are sent to the database. The database performs the expansion itself. That allows the database to set up a query plan that will work for different values of the parameters.
Microsoft always uses #parname for parameters. Oracle uses :parname. Other databases are different.
No database I know of allows you to specify the table name as a parameter. You have to expand that client side, like:
command.CommandText = string.Format("DELETE FROM {0}", tableName);
P.S. A * is not allowed after a DELETE. After all, you can only delete whole rows, not a set of columns.

SSRS Text Query: Variable names must be unique within a query batch or stored procedure

I am developing an SSRS 2008 report, but instead of using stored procedures, I want to use all Text queries. This report was working with stored procedures, but when I changed this report to use same logic but via text queries, I got the following error:
An error occurred during local report processing
    Query execution failed for dataset 'BRSR_Totals'
        The variable name '#END_yEAR' has already been declared. Variable names must be unique within a query batch or stored procedure.
Operation cancelled by user.
The problem is that some of my datasets (text queries) re-use the same parameters and END_YEAR is one of these parameters. How do I make this report run correctly?
One area that you might want to check is case sensitivity. SSRS is case-sensitive when considering parameter names but T-SQL does not have that case sensitivity. Take another look at your code and make sure that all parameters are using the same case.
I just resolved a similar issue using a text query to populate a dataset. It worked in SQL Server Management Studio and it worked in the Query Designer within BIDS, but failed at runtime.
The issue turned out to be BIDS helpfully adding parameters to the Dataset that this query was referencing. Switching to the Parameters tab of the Dataset Properties showed that BIDS had duplicated the parameters I had already added earlier. Deleting the duplicates resolved my problem.
To respond to the suggestion that the logic be off-loaded into a stored procedure: in this case, the report is a custom report for a single customer. The query will only ever be used in this report and makes a few assumptions about the customer's configuration that should not be available globally
I also just fixed this same issue in one of my queries. I was using a text query and had datetime variables/parameters. SSRS added a second set into the parameters for the dataset properties. I deleted them and my query ran fine after that and my graph populated.
I ran into a similar issue on a report where I had declare a substantial number of parameters at the beginning that I didn't want the end user to see. The issue I had was I was using a comma at the beginning of the line, so I had:
DECLARE #Parameter VARCHAR(4) = 'text'
, #Parameter VARCHAR(4) = 'text2'
It worked just fine in SSMS, but when I ran it in Report Builder 3.0 it threw the error shown in this thread. I changed it to remove the comma and to restate DECLARE at the beginning of each line and it worked perfectly.
Check that you didn't declare it twice, once in the CREATE PROC statement you're creating and another in the actual code...I've seen this problem while testing changes to SP code.