I have a problem with Oracle 'bind variables' and ActiveRecord.
How AR can use 'bind variables'?
I am trying to use oracle and oracle-enhanced adapters, set cursor_sharing directives to 'force' or 'similar', but result SQL query does not contain bind vars, only plain string.
I am using AR 2.0.2 and 3.1+.
And maybe console verbose does not show full SQL query?
With cursor_sharing = FORCE, it is unlikely that bind variables are not being used, but RoR will not know anything about them. Active Record will still send the queries to the database without binds, and then Oracle will force bind variables into the place of all literals. Therefore in the Rails console, you will just see the original SQL with no binds.
To confirm your SQL statements are using binds, query v$sql with something like:
select sql_fulltext
from v$sql
where upper(sql_fulltext) like '%TABLE IN YOUR APP%'
You should see your original queries in the output, but with bind variables in place of the values you had passed in.
Related
I use postgreSQL/pentaho CDE. I need to transmit parameter as schema prefix in my query. I need to run this query: select * from peredelkino_public.protocol
I used custom parameter in Pentaho (named 'selector_par'), in properties named 'Javascript code' i wrote 'peredelkino_public.protocol'.
Then I changed sql query in component 'sql over sqlJndi' like this: select * FROM (${selector_par})
But this query doesn't work! I get message 'Error processing component'. How I can transmit schema prefix in my query?
Check the Replace variables in script.
Note: if the parameter selector_par does not exists or is misspelled, you may get a hard to understand error message.
You cannot.
CDE can only use JDBC parameters and those cannot be used in the from clause.
If you absolutely need to do that, you should use a Kettle datasource in CDE, as PDI allows any variable to be used in any part of a SQL query.
But make sure you sanitize your inputs. Variable replacements such as that one are a gold mine for hackers.
I have the following SQL script (all names replaced with metasyntactic variables):
DELETE FROM FOO
WHERE UPPER(BAR)=? AND UPPER(BAZ)=? AND UPPER(QUX)=? AND UPPER(QUUX)=? AND UPPER(CORGE)=?;
When I run it in SQL Developer, I get the following error, as expected: SQL Error: Missing IN or OUT parameter at index:: 1
Is there a way in SQL Developer to pass test parameters to these values (in this case, BAR, BAZ, QUX, QUUX, and CORGE) or do I have to manually replace the question marks? Thanks!
UPDATE: I've been looking on the internet to try to find the answer with no luck; none of the articles I found deal with the FOO=? syntax. I know that that is the proper syntax to access (and in this case, delete from) the database from a Java program, but I would like to test the SQL script before embedding it in the program.
A query that way is called a prepared statement. It is used as a way to send SQL statements from a program to the database.
First you have to prepare the prepared statement object and later you supply the parameters and finally execute the statement. When setting the parameters, you refer to each question mark in the order they apear in the statement. So in you case, BAR would be parameter 1 and CORGE will be parameter 5.
http://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html
For testing a query like this is quite useless in my experience. You could change the paramters to variables or even substitution variables if that is more convenient while testing.
http://docs.oracle.com/cd/B19306_01/server.102/b14357/ch5.htm#i1211130
3GLs provide mechanisms to prepare statements before executing them. E.g.
SELECT name
FROM people
WHERE age=:AGE
The same query can then be executed for different ages. But can such a statement also be prepared in a "plain" Oracle SQL client? Can the same be done in e.g. SQL Plus or dbForge Studio for Oracle as in Java or C# or any other programming language that supports prepared statements?
In dbForge Studio for Oracle, named parameters can be used, preceded by a colon :
SELECT *
FROM people
WHERE name=:name
The parameters can then be filled in with the "Edit parameters dialog box", available from the SQL toolbar.
I know you didn't ask about PostgreSQL but about Oracle. However, of note, PostgreSQL has this feature right in its SQL language.
The SQL standard includes a PREPARE statement, but it is only for use in embedded SQL. The PostgreSQL version of the PREPARE statement works like this:
PREPARE nameByAge(number) AS
SELECT name
FROM People
WHERE age=$1;
and you use it like this:
EXECUTE nameByAge(18);
EXECUTE nameByAge(50);
So unfortunately for Oracle SQLPlus the answer seems to be no, not bind variables. But SQLPlus has substitution variables, similar to shell scripts. You use them as &1, &2, &3, ... and they get their parameters from the way you call the SQLPlus script.
sqlplus user/password #script.sql 18
sqlplus user/password #script.sql 50
with the script.sql being
SELECT name
FROM People
WHERE age=&1;
this would work, even though it is not bind. But then, do you really care about the slight savings in repeat parse time? In fact Oracle hashes SQL statements and already replaces constants with bind variables to be able to better reuse query plans. So the savings you would get with PREPARE and BIND are really minuscule.
We have a database setup where we have a separate user for owners and users of database tables in an Oracle database. This means that in practice each query is prefixed like this: ownername.tablename
This works just fine if I just write the whole thing statically in Slick's SQLInterpolation.sql function:
(sql"select foo_owner.foo_sequence.nextval from dual").as[Long].first()
The problem is, that the owner prefix changes depending on test/prod. environment. What I'd like to do is this:
(sql"select $owner.foo_sequence.nextval from dual").as[Long].first()
But SQL interpolation doesn't work with it. I get this error Oracle:
An exception or error caused a run to abort: ORA-22806: not an object or REF
Any suggestions? I can of course fall back to the more verbose StaticQuery, but using sql/sqlu interpolation would be much more compact.
Using $foo inserts foo as a bind variable. You need to prefix it with # to insert a literal:
(sql"select #$owner.foo_sequence.nextval from dual").as[Long].first()
Is removing prefix acceptable? In your code you can run
ALTER SESSION SET CURRENT_SCHEMA=yourOwner
This way you do not need to prefix SQL. Just be sure that you do not have CREATE TABLE or any other DML as it will try to run it on owner's schema.
Using parameters instead of placing values directly in the query string is done to prevent SQL injection attacks and should always be done:
... WHERE p.name > :name ...
->setParameter('name', 'edouardo')
Does this mean that if we use parameters like this, we will always be protected against SQL injections? While using a form (registration form of FOS), I put <b>eduardo</b> instead and this was persisted to the database with the tags. I don't really understand why using parameters is preventing against SQL injections...
Why are the tags persisted to the database like this? Is there a way to remove the tags by using Symfony's validation component?
Is there a general tip or method that we should be using before persisting data in the database in Symfony?
Start with reading on what's SQL injection.
SQL injection attack takes place when value put into the SQL alters the query. As a result the query performs something else that it was intended to perform.
Example would be using edouardo' OR '1'='1 as a value which would result in:
WHERE p.name > 'edouardo' OR '1'='1'
(so the condition is always true).
"<b>eduardo</b>" is a completely valid value. In some cases you will want to save it as submited (for example content management system). Of course it could break your HTML when you take it from the database and output directly. This should be solved by your templating engine (twig will automatically escape it).
If you want process data before passing it from a form to your entity use data transformers.
If you use parameters instead of concatenation when creating a request, the program is able to tell SQL keywords and values apart. It can therefore safely escape values that may contain malicious SQL code, so that this malicious does not get executed, but stored in a field, like it should.
HTML code injection is another problem, which has nothing to do with databases. This problem is solved when displaying the value, by using automatic output escaping, which will display <b>eduardo</b> instead of eduardo. This way, any malicious js / html code won't be interpreted : it will be displayed.