I'm having a problem I haven't encountered before: there is a stored function in a database: CC_PROC, which takes two date entries and returns a table. In other words, to call it, you type:
SELECT * FROM (TABLE( CC_PROC( DATE '2012-01-01', DATE '2012-01-15')));
This seems to work perfectly in SQLPlus and NetBeans, and the above line has been apparently been in use for some time.
Anyway, when calling it from java using a prepared statement, I get: "CC_PROC": invalid identifier on the executeQuery call.
This is with:
PreparedStatement preparedStatement =
connection.prepareStatement("SELECT * FROM (TABLE ( CC_PROC( ? , ? )))");
preparedStatement.setDate(1,firstDate);
preparedStatement.setDate(2,secondDate);
resultSet = preparedStatement.executeQuery();
I feel like maybe this is obvious and my limited experience using JDBC directly instead of Hibernate is throwing me. I'd like to not have to re-code the contents of CC_PROC in java business logic. Any ideas?
Thanks!
Aha, found the answer:
The oracle user was SALESOWN, so the fix was:
PreparedStatement preparedStatement = connection.prepareStatement(
"SELECT * FROM (TABLE ( SALESOWN.CC_PROC( ? , ? )))");
Yikes. I don't want to admit the amount of time it took to figure that out.
Apparently SQLPlus and NetBeans do attempt to help out a little...
Thanks for the help guys!
Related
i am trying to select tables from my mysql database , and the tables names may be any thing unsafe, since users choose them, i have tried to do it like this :
String table = "*jjs> o";
PreparedStatement stmt = conn.PrepareStatement("SELECT * FROM ? ");
stmt.setString(1,table);
stmt.executeQuery();
but seems it to throw exception due to unacceptable command, can some one help me how can i achieve that please? thanks
add a back tick(`) to table name
select * from `*jjs> o`
Ok Using BackTicks Was the Answer, Like select * from `*jjs> o` without statement.Thanks Alot
I have a java servlet application and I'm using a prepared query to update a record in a SQL Server Database table.
Lets say I want to execute UPDATE MyTable SET name = 'test' WHERE id = '10'. (Yes, id is a varchar)
I used the following code to make this happen:
PreparedStatement pstmt = con.prepareStatement("UPDATE MyTable SET name = ? WHERE id = ?");
pstmt.setString(1, getName() );
pstmt.setString(2, getID() );
pstmt.executeUpdate();
I found out that while I was running a JMeter script to simulate 2 users, this statement causes a deadlock in my database.
I wanted to check what my values were in the SQL Profiler so I used the following code, so I could check the values.
String query = String.format("UPDATE MyTable SET name = '%s' WHERE id = '%s' ", getName(), getID() );
PreparedStatement pstmt = con.prepareStatement(query);
pstmt.executeUpdate();
Suddenly my deadlock was gone! It's a shame the last approach is vulnerable to SQL injection.
Is there somebody who can tell me what is going on and/or how to fix it?
Ok I finally found the problem and solution to my problem.
It seemed that the combination of the jTDS JDBC driver with MSSQL was the 'problem'.
This article explained my situation exactly. And with the help of this FAQ I was able to set the datasource to the right configuration.
From what I understand:
If you have statement that uses a String-like index (Like in my situation), the table performs an index SCAN instead of an index SEEK. This causes the whole table to be locked and vulnerable to deadlocks.
I hope this will help other people too.
I am trying to select some values in my table but when Invoicedate is null I got exception please help me!
my code :
query="select vend_name,vend_no from account where inv_date = '"+Invoicedate+"' or vend_no = "+Vendorno+" LIMIT 500";
please give any possible answer to me.
That's because in your code it will become inv_date = 'null' not inv_date is null.
You need to do inv_date "+(Invoiceddate==null?"is null":"= '"+Invoiceddate+"'")+" or
In general this is a bad way to do things though as you are open to SQL injection attacks and all sorts of other similar problems.
Use a PreparedStatement and all this will be handled for you:
PreparedStatement query = connection.prepareStatement("select vend_name,vend_no from account where inv_date = ? or vend_no = ? LIMIT ?");
query.setDate(1, Invoicedate);
... etc
Note also that you should follow the Java style conventions in variable naming etc, it will help people work with your code.
I have a big but INTERMITTENT problem with a bug in Oracle 10g when we call some SQL within a Java web application. We can't quickly patch or upgrade to 11g - which seems to be the first 'stupid' oracle support response. There is a work around, but I am having trouble doing this within PreparedStatements within my Java code.
The actual error is:
ORA-00600: internal error code, arguments: [kcblasm_1]
The bug is: Oracle Bug 12419392
The work around is running
alter session set "_hash_join_enabled" = FALSE;
before we run our bug-inducing SQL. However, traditionally a PreparedStatement takes in one single piece of SQL:
PreparedStatement stmt = con.prepareSelect("sql statement2");
Is it possible to have one PreparedStatement call that looks like this:
PreparedStatement stmt = con.prepareSelect("sql statement1; sql statement2;");
Or is this possible just by running a series of sequential PreparedStatements one after the other?
Not the best time to be getting this with Xmas looming and reduced support etc. etc., so I really hope someone can help. Thanks.
Edit: #jonearles asked for the code, so here it is, if it's on any use. Probably very specific to our project, but someone might spot the glaring bug-inducing issue:
SELECT DISTINCT qm.validator_id,
qm.QM_ID,
u.EMAIL,
qm.creation_dt,
qm.emailed,
qm.valid,
qm.resolved,
qm.new_obs_id,
o.*,
nests.*,
s.*,
l.*,
latc.TENKM
FROM query_man qm,
obs o,
obs_aux_aon nests,
sub s,
location l,
l_atlas_tetrad_coverage latc,
users u
WHERE qm.OBS_ID = o.OBS_ID
AND o.SUB_ID = s.SUB_ID
AND u.user_id = qm.user_id
AND o.obs_id = nests.obs_id(+)
AND s.LOC_ID = l.LOC_ID
AND latc.ATLAS_REGION = 'NKNE'
AND (LENGTH (l.gridref) = 6
AND (SUBSTR(l.gridref,1,3)
|| SUBSTR(l.gridref,5,1)) = latc.TENKM
OR LENGTH (l.gridref) = 4
AND l.gridref = latc.TENKM)
AND qm.RESOLVED IS NULL
ORDER BY latc.tenkm,
l.tetrad
OK. The answer to my primary question is NO, you can't create a PreparedStatement like so:
PreparedStatement stmt = con.prepareSelect("sql statement1; sql statement2;");
Running individual statements to alter session temporarily for one bit of SQL did work, but agreed seems awful and also unacceptably slowed response. Options seem to be patch or upgrade, or look into the no_use_hash hint (which I think will be slow too). Will look at code.
Excerpt from code
PreparedStatement preparedStatement = connection.prepareStatement("SELECT * FROM sch.tab1 where col1 like lower ( 'ABZ' ) ");
preparedStatement.executeQuery();
The above code executes successfully.
But when i try to execute this
PreparedStatement preparedStatement = connection.prepareStatement("SELECT * FROM sch.tab1 where col1 like lower ( ? ) ");
preparedStatement.setString ( myValue );
preparedStatement.executeQuery();
It throws an exception."STRING TO BE PREPARED CONTAINS INVALID USE OF PARAMETER MARKERS"
What could be the problem here?
Answer found, see the comments
I suspect the problem is that you can't apply functions directly to parameters. Is there any particular reason why you want the lower casing to be performed at the database rather than in your code? (I can think of some potential reasons, admittedly.) Unless you really need to do this, I'd just change the SQL to:
SELECT * FROM sch.tab1 where col1 like ?
and call toLower() in Java, preferably specifying the appropriate locale in which to perform the lower-casing.
I think Carlos is on to something. Try
SELECT * FROM sch.tab1 where col1 like lower ( '' + ? )
or whatever passes for string concatenation operator in your version of SQL. Forcing a string context might get you past the error. May require extra parentheses.
For reference: I ran into the same problem while using the NORMALIZE_STRING function:
SELECT NORMALIZE_STRING(?, NFKD) FROM sysibm.sysdummy1
Error message:
THE DATA TYPE, LENGTH, OR VALUE OF ARGUMENT 1 OF NORMALIZE_STRING IS INVALID. SQLCODE=-171, SQLSTATE=42815, DRIVER=4.13.111
Using the following statement solved the problem (CONCAT). Thanks to Paul Chernoch!
SELECT search_normalize(NORMALIZE_STRING(? CONCAT G'', NFKD)) FROM sysibm.sysdummy1
Note the "G" prefix for Unicode compatibility.