Say that I have a large SQL table. I want to get specific data out of the table and into a 2sxc module.
SQL Query:
select * from myTable where dataCategory=
What I need to do is pass from the 2sxc module down into the data source.
Is that possible? The parameter will come to the module as a querystring value.
No problem :)
Use something like Select * from myTable where dataCategory = [QueryString:category]
You'll have to check if you need to wrap it in quotes like '[QueryString:category]' or without the quotes, I think it's without the quotes.
The sql data source even does additional parsing to ensure you're protected from SQL inject. So internally it actually converts it to a Select ... where dataCategory = #p1 and then tells the server that #p1 = 'cake' or whatever was in the url.
Related
I am trying to get codes that have certain combination of characters in a query in sql server.
Instead of saying in SQL Server
and TIL.code LIKE '%tf%' or code like 'fs%' or code like '%ls%'
Is there a single pattern I can use
If your goal is to avoid the ORs, rather than use Regex (which SQL Server doesn't support) you could use an EXISTS:
AND EXISTS (SELECT 1
FROM (VALUES('%tf'),('fs%'),('%ls%'))V(Pattern)
WHERE TIL.Code LIKE V.Pattern)
If this is coming from a parameter, you would use a table type parameter, and then replace the VALUES table construct with that parameter:
AND EXISTS (SELECT 1
FROM #YourTableTypeParameter TTP
WHERE TIL.Code LIKE TTP.YourPatternColumn)
I want to send the date range and employee ids from SSRS to Oracle package. Does anyone knows how to do it? Even if i try to declare an oracle package with three in parameters from_date, to_date and employee_id it works fine with one employee id. But fails if i select multiple employees in SSRS web interface saying wrong number of parameters. Does anyone know how to handle this?
Normally with SQL and SSRS you would do something like
Select * From Table where Table.Field in #Param
Oracle is different of course and depends on the Connection Type you are using.
ODBC connection you would use something like:
Select * From Table where Table.Field = ?
Order of the parameters is important here so be careful.
OLEDB connection you would use something like:
Select * From Table where Table.Field = :Param
However, none of the above work with multi selecting of the Parameters. You could do this:
=”Select * From Table where Table.Field in (‘” + Join(Parameters!parameter.Value,”‘, ‘”) + “‘)”
or
=”Select * From Table where Table.Field in(” + Join(Parameters!parameter.Value,”, “) + “)” if the values or your field is only numeric.
Here are a couple of good articles that you can look at. It has a better explanation than I can give personally without more information; Details of your Oracle Environment, Connection Type, etc.
Quick Reference:
Be sure your Oracle version is 9 or greater, none of this works on
versions 8 or older.
When using parameters with Oracle, use a : instead of an # sign –
:param instead of #param.
Add an ‘ALL’ option to your datasets that supply values for
multivalued drop down parameters.
Check for the ALL in your where clause by using “where ( field1 in (
:prmField1 ) or ‘ALL’ in ( :prmField1 ) )” syntax.
You can execute your query from the dataset window, but can only
supply 1 value. However that value can be ‘ALL’.
Educate your users on ‘ALL’ versus ‘(select all)’ .
Another good article about Multiple Parameters in SSRS with Oracle: Davos Collective Which is referenced in the top portion.
Hope this helps!
The problem is this - I'm usign SQL Server 2012 and I have 3 Linked IBM DB2 servers so I need to use OPENQUERY. However whe I tried to use :
command.Parameters.AddWithValue("#param", clientId);
I get error : an error occurred while preparing the query..
After some time of investigantion I figured out that if I use concrete value in my query instead of trying tu pass it with parameter everything was working fine, so I get to the conclusion that the problem is not in my query or more precisely maybe it's in the query but because I'm trying to use #param. The after further investigation I got this: OPENQUERY does not accept variables for its arguments. which I think seems to be the problem even though this is from year 2008 so the information is a little bit outdated.
However the best option would be to find a way to use parameters inside OPENQUERY but if that's really impossible in this scenarion what would be a save approach to pass the variable to my query?
As you found out, you cannot use parameters using OPENQUERY. Instead you could build up your SQL query and embed the values. So rather than this:
var sql = "select * from openquery(LinkedServer, 'SELECT * FROM MyTable WHERE tbl.ID = #param')";
You can do:
var someParameter = "SomeValue";
var rawQuery = "select * from openquery(LinkedServer, 'SELECT * FROM MyTable WHERE tbl.ID = ''{0}''')";
var sql = string.Format(rawQuery, someParameter);
However, you now need to be very careful of things like SQL injection.
I am trying to issue a SQL update statement with nHibernate (2.0.1GA) like this:
sqlstring = string.Format("set nocount on;update myusers set geo=geography::Point({0}, {1}, 4326) where userid={2};", mlat, mlong, userid);
_session.CreateSQLQuery(sqlstring).ExecuteUpdate();
However I receive the following error: 'geography#p0' is not a recognized built-in function name.
I thought CreateSQLQuery would just pass the SQL I gave it and execute it...guess not. Any ideas on how I can do that within the context of nHibernate?
I'm pretty sure I can tell you what is happening, but I don't know if there is a fix for it.
I think the problem is that the ':' character is used by NHibernate to create a named parameter. Your expression is getting changed to:
set nocount on;update myusers set geo=geography#p0({0}, {1}, 4326) where userid={2};
And #p0 is going to be a SQL variable. Unfortunately I can't find any documentation for escaping colons so they are not treated as a named parameter.
If an escape character exists (my quick skim of the NHibernate source didn't find one; Named parameters are handled in NHibernate.Engine.Query.ParameterParser if you want to spend a little more time searching), then you could use that.
Other solutions:
Add an escape character to the source. You can then use a modified version of NHibernate. If you do this, you should submit your patch to the team so it can be included in the real thing and you don't have to maintain a modified version of the source (no fun).
Create a user defined function in your DB that returns a geography::Point, then call your function instead of the standard SQL function. This seems like the quickest/easiest way to get up and running, but also feels a bit like a band-aid.
See if there is something in NHibernate Spatial that will let you programmatically add the geography::Point() [or edit the code for that project to add one and submit the patch to that team].
"{whatever} is not a recognized built-in function name" is a SQL Server error message, not sure what Hibernate is doing there but SQL Server is the one complaining about it.
There is an implicit conversion from varchar to Point.
Use NHibernate to set the geographic parameters to their string representation
Define a SQL query template with named paramter loc:
const string Query = #"SELECT {location.*}
FROM {location}
WHERE {location}.STDistance(:loc) is not null
ORDER BY {location}.STDistance(:loc)";
Set the parameter to a string representation of Point:
return session
.CreateSQLQuery(Query)
.AddEntity("location", typeof (Location))
.SetString("loc", "Point (53.39006999999999 -3.0084007)")
.SetMaxResults(1)
.UniqueResult<Location>();
This is for a Select. but I see no reason why it wouldn't work for an Insert or Update.
Following on #Chris's answer, here is a copy and paste solution:
CREATE FUNCTION GetPoint
(
#lat float,
#lng float,
#srid int
)
RETURNS geography
AS
BEGIN
declare #point geography = geography::Point(#lat, #lng, #srid);
RETURN #point
END
GO
The you do
dbo.GetPoint(#Latitude, #Longitude, 4326)
instead of
geography::Point(#Latitude, #Longitude, 4326);
And NH is happy
I writing a report in Visual Studio that takes a user input parameter and runs against an ODBC datasource. I would like to write the query manually and have reporting services replace part of the where clause with the parameter value before sending it to the database. What seems to be happening is that the #parmName I am assuming will be replaced is actually being sent as part of the SQL statement. Am I missing a configuration setting somewhere or is this simply not possible?
I am not using the filter option in the tool because this appears to bring back the full dataset from the database and do the filtering on the SQL Server.
It sounds like you'll need to treat the SQL Statement as an expression. For example:
="Select col1, col2 from table 1 Where col3 = " & Parameters!Param1.Value
If the where clause is a string you would need to do the following:
="Select col1, col2 from table 1 Where col3 = '" & Parameters!Param1.Value & "'"
Important: Do not use line breaks in your SQL expression. If you do you will get an error.
Holla back if you need any more assistance.
Doesn't ODBC use the old "?" syntax for parameters? Try this:
select col1, col2 from table1 where col3 = ?
The order of your parameters becomes important then, but it's less vulnerable to SQL injection than simply appending the parameter value.
Encountered same problem trying to query an access database via ODBC.
My original query: SELECT A.1 FROM A WHERE A.1 = #parameter resulted in error. Altered to: SELECT A.1 FROM A WHERE A.1 = ?.
You then have to map the query parameter with your report parameter.
I am a bit confused about this question, if you are looking for simple parameter usage then the notation is :*paramName* , however if you want to structurally change the WHERE clause (as you might in sql+ using ?) then you should really be using custom code within the report to define a function that returns the required sql for the query.
Unfortunately, when using custom code, parameters cannot be referenced directly in the generated query but have to have there values concatenated into the resultant String, thus introducing the potential for SQL injection.