i want to sort my result based on parameter:
select ... group by some_column :paramter
and the parameter should be asc or desc. but when i try it, i get error:
ERROR: syntax error at or near "$6"
is it possible in postgres? if i send the query from the server, i can just concatenate the query but what if it's inside a stored procedure? i would prefer to avoid concatenating strings to build a query
SQL parameters cannot be placed in that location. They are meant to apply scalar values to the SQL template, but not to modify the SQL query structure itself.
What you need is to implement "Dynamic SQL" here, but that's a different strategy.
Related
Is there a way in PostgreSQL to access fields without explicitly providing the column name? For example, instead of the statement:
select (col1,col2,col3,...col42) from foo_table;
there's a (possible) alternative of:
select (1:42) from foo_table;
There is no such syntax in Postgres' SQL.
You could always resort to having code that dynamically constructs the query for you before executing it, but that's about as good as it will get.
I'm attempting to write an extension for SQL Developer to better support Postgres. These are just XML configuration files with SQL snippets in them. To display the values for a postgres sequence, I need to run a simple query of the following form:
select * from schema.sequence
The trouble with this is that the Oracle SQL Developer environment provides the correct schema and node (sequence) name as bind variables. This would mean that I should format the query as:
select * from :SCHEMA.:NAME
The trouble with this is that bind variables are only valid in the select clause or the where clause (as far as I'm aware), and using this form of the query returns a "syntax error at or near "$1" error message.
Is there a way to return the values in the sequence object without directly selecting them from the sequence? Perhaps some obtuse joined statement from pg_catalog tables?
Try this:
select *
from information_schema.sequences
where sequence_name = :name
and sequence_schema = :schema;
It's not exactly the same thing as doing a select from the sequence, but the basic information is there.
I want to use the "split" function in a simple query on my SSRS 2008 report. However, I get an error "Query execution failed for dataset "SlsmRealNum". "Split" is not a recognized built-in function name". But it's listed as a common function (text) if I open up the Expression box on the query, so not sure why it's failing?
my simple select statement is:
select slsm_num, slsm_msid from Salesman where slsm_msid = split(User.UserID,"\").GetValue(1)
right now to get the report to work, I have one parameter (SlsmnNum) that has the Split expression in it (to get the MSID of the user) and then a 2nd parameter that uses the above query in the Dataset Salesrepum using the #SlsmnNum parameter as the MSID. I'd like to not have to have 2 parapmeters if possible and just get the actualy salesrep # in just one. Any help is greatly appreciated!
Your select statement is executed as SQL so the error you are getting is actually from SQL server. This may be where you are getting confused.
There are two components to SSRS - SQL Statements and Report Expressions. Typically, SQL statements are used to generate datasets by querying the database. Report expressions are used to organize, aggregate, and filter the dataset once obtained from the SQL database. Since the SQL statement is executed IN the SQL database, only the functions that are in the database are available. The code you posted is a SQL statement not a Report Expression.
For example, you can't take a Report Expression and expect it to work in SSMS? No, because they are two different entities with wholly different syntax and purpose. When it comes to using built-in SSRS functions inside a SQL statement it will not work, the database has no concept of what the built in User.UserId is and as such you must use a parameter to transport the value over to the SQL query. This is definition and purpose of a parameter and why they exist.
Split is a function in SSRS which is why you see it in your expression reference, however, it is not a function in SQL. The code you posted is SQL syntax, so I am betting that this is the SQL statement that you are using to obtain your dataset. Therefore the query fails since the SQL DB does not have a Split Function.
You can add this split function to your database and the code is located here: Split String in SQL. You could also use something along the following in your where clause, the following is your updated SQL statement.
SELECT slsm_num, slsm_msid from Salesman where slsm_msid = SUBSTRING(#UserId, PATINDEX('%\%', #UserId), LEN(#UserId))
You would set the #UserId parameter's value to an expression of User!UserID rather than specifying it in your select statement.
The SSRS expression examples have a function similar to what your code is trying to accomplish if you were wanting the same thing in the report side. The function you are looking for is InStr(). On your report side you could use something along the lines of:
=Parameters!User.Value.Substring(Parameters!User.Value.IndexOf("\")+1, Parameters!User.Value.Length-Parameters!User.Value.IndexOf("\")-1)
Expression examples can be found here: MSDN Expression examples.
I have a query like
SELECT *
FROM myTable
WHERE key LIKE 'XYZ'
The value 'XYZ' is entered by users (and may include % and _)
If I construct the query using string concatenation it runs in 10 seconds.
But this is unsafe, and I should use a parameterised query.
So I'm constructing the query using the odbc command object and it's execute method, and passing a parameter.
SELECT *
FROM myTable
WHERE key LIKE ?
Unfortunately the parameterised SQL execute method takes a full minute.
This query is one of many that are part of a drill-down / investigation package, and I've had similar slow downs with all the parameterised queries (compared to string concatenation).
How do I find out where the time is going (and fix it) ?
Here's my guess without further information.
I've had similar problems on SQL Server. In SQL Server when the column on your table is 'varchar' and the parameterised query parameter is 'nvarchar' (or vice versa), this causes SQL Server to ignore an available index because the parameter type doesn't match the index type, which in turn results in a table scan.
It's possible the same thing happens for Sybase. If you can see the generated query you can confirm if there's a type mismatch.
If this is the case, then two solutions would be
explicitly set the type of the parameter to match the column type
change the type of the column to match the parameter type being generated
Mitch had the right suggestion.
I had to change the connection string to use the OLEDB driver, then I could set the options:
Optimize Prepare=None
Select Method=Direct
I have a question regarding SQL. I have the following SQL statement:
SELECT id, First, Last, E_Mail, Notes
FROM mytable
WHERE SOMETHING_SHOULD_BE_HERE IS NOT NULL;
I know that the SOMETHING_SHOULD_BE_HERE should be a column(attribute) in my table. Is their a way I can put a variable that can refer to the column I'm trying to access? In my case their are 30 columns. Can I have a string for SOMETHING_SHOULD_BE_HERE that can be assigned in my program to the column in which I want to search?
Thanks
No. Variables in SQL can refer to data, but not to object names (columns, functions or other database objects).
If you are building the SQL query, you'll need to use string operations to build your query.
The column can't be variable, but the value of the column can. The parser needs to know what to bind to.
If you elaborate on what you're trying to solve and which platform you're using it would allow for more complete answers.
You can have different SQLs queries in your code and use each one according to the case.
Another way is generate dynamically the query according the fields you want.
Without dynamic SQL, this is probably your best bet:
SELECT
id, first, last, email, notes
FROM
My_Table
WHERE
CASE #column_name_variable
WHEN 'column_1' THEN column_1
WHEN 'column_2' THEN column_2
...
ELSE 'not null'
END IS NOT NULL
There might be some issues with data type conversions, so you might need to explicitly cast all of the columns to one data type (VARCHAR is probably the best bet). Also, there's a good chance that performance will be horrendous on this query. I'd test it thoroughly before even thinking about implementing something like this.
I mentioned this in my comment, but for completeness I'll put it here too... you can probably also accomplish this with dynamic SQL, but how you do that will depend on your database server (MS SQL Server, Oracle, mySQL, etc.) and there are usually some caveats to using dynamic SQL.
In JDBC program, yes,the select statement can be composed like string operation.
for(String colName: colList)
{
String sql="Select id, First, Last, E_Mail, Notes From mytable where "+colName+" IS NOT NULL";
//execute the sql statement
}
It depends on how you are going to find out the value of SOMETHING_SHOULD_BE_HERE.
If you are in an Oracle PLS/SQL environment you could build up the WHERE clause using dynamic SQL and then use EXECUTE IMMEDIATE to execute it.
If you have a small set number of possibilities you could use CASE to workaround your problem possibly.
Your question is unclear.
However I am quite sure that what you have in mind is the so-called dynamic SQL (and related). "Dynamic SQL" allows you to dynamically build and submit queries at runtime. However such functionalities may not exist for your RDBMS.
There are several ways to do this.
When your query would return one and only one row
then you have to consider the EXECUTE IMMEDIATE statements (along with sp_executesql in tSQL : http://msdn.microsoft.com/en-us/library/ms188001.aspx ; or the USING clause in PL/SQL : http://docs.oracle.com/cd/B14117_01/appdev.101/b10807/13_elems017.htm to specify a list of input/output bind arguments) and/or PREPARED statements (http://rpbouman.blogspot.fr/2005/11/mysql-5-prepared-statement-syntax-and.html).
When your query can return more than one row
then you have to consider techniques such as the EXECUTE IMMEDIATE statement with the BULK COLLECT INTO clause or the OPEN-FOR, FETCH, and CLOSE statements (explicit cursors in PL/SQL :
http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/dynamic.htm)
Please note that except in some particular cases, most conventional techniques like IF-THEN-ELSE and CASE statements should be preferred (along with a good algorithm). Furthermore they work with almost all RDBMS.