JDBC Inconsistent with LIKE - jdbc

Im new with JDBC, and while executing some query i get a result that is inconsistent.
If i execute this query in sql developer (connected to a Oracle DB) i get 4 results
SELECT *
FROM someTable1 some1
JOIN someTable2 some2 on (some1.some_id= some2.other_id)
WHERE some2.some_date LIKE '01/01/01' OR some2.some_date IS NULL
Then, i load this same query from a properties file in java and execute the query and get 0 results... anyone know why this is happening? I first suspect of the single quotes in the propertie value but i dont know...
Thanks in advance and excuse my poor english! :)

The query doesn't contain any special characters which could confuse Java, the properties loader or JDBC, so you should get exactly the same results in SQL Developer and with JDBC.
In fact, SQL Developer is written in Java, so it is using JDBC to execute the queries.
Print the query to the console before you execute it to make 100% sure the code executes the query that you have in mind.
Next, you should check the type of some_date. LIKE is only defined for string types (VARCHAR and similar), not for date/time types.
Oracle has a set of helper functions to build queries for date/time types, for example:
some_date = to_date( '01/01/2001','mm/dd/yyyy')
or
TRUNC(some_date, 'DAY') = to_date( '01/01/2001','mm/dd/yyyy')
The second query strips hours, minutes, seconds, etc. from the column and will compare only days, months and years.
Note: Always use 4-digit years to avoid all kinds of odd problems.

Related

Oracle's SQL Developer Database Export Results in 2 Digit Years

I'm using Oracle's SQL Developer to export data into CSVs. I found that Oracle spits out the dates as dd-MMM-yy. When I bulk insert these files into SQL Server it's interpreting some of the dates incorrectly. How do I change that?
I'm an Oracle neophyte, so I might be approaching this whole thing incorrectly. I need to transfer a lot of tables/rows from Oracle to SQL Server. I have a linked server set up in SQL to Oracle, but that takes a really long time to transfer the data. About 18 hours, and both databases are on the same server, but it gets the dates correct.
I didn't find any good way to accomplish this other than a couple of PL/SQL scripts I couldn't get to work for me. Is it really that rare that data gets migrated from Oracle to MS-SQL?
Well, dates across database vendors are just hell.
The default date format can be set in SQL Developer Preferences > Database > NLS > Date Format. You can also set it in the session as #belayer has commented.
For writing CSV files or for migration projects, I would always try to control the format directly, like
SELECT id, TO_CHAR(my_date,'YYYY-MM-DD') AS my_date, my_column
FROM my_table;
Having said that, there should be a better way to move the data out of Oracle into SQL Server...

Oracle to_date format issue

I have an insert statement, where one of the inserted fields is date. I use to_date function to convert string to date in this way:
to_date('10-MAY-10', 'DD-MON-RR')
It works fine, but I found, that it allows also variants like:
to_date('10?MAY?10', 'DD-MON-RR')
to_date('10+MAY+10', 'DD-MON-RR')
I'm expecting an Oracle error, however it makes an insert. Could you please explain why or give a reference to relevant documentation?
Oracle will test for other formats if it fails to find a match in the string - you can see the rules for what it looks for here in the documentation.
As an aside, years have four digits. Please make sure you specify all four when you provide a date-as-a-string, where possible; it saves the database from having to guess and potentially getting it wrong. I.e. your original example should be:
to_date('10-05-2010', 'DD-MM-YYYY')
If you need to restrict the date-as-a-string to a specific format, you can use the fx format modifier, which is mentioned earlier in the same document I linked to previously.
eg. to_date('10/05/2010', 'dd-mm-yyyy') would match but to_date('10/05/2010', 'fxdd-mm-yyyy') would fail

How to identify column types during sql injection?

Situation is following:
I have identified sql injection attack vector, and have following information about target table:
It has six columns. (Identified using "order by").
I can see output of 3 of them (table is displayed). two seems kind of enum value (integer in database?), and one is a date. I have very strong suspicion that col #6 is date column.
I'm almost sure the database is oracle. (ROWNUM works and LIMIT gives error).
I don't have error messages (always generic text is returned - "something went wrong").
Frontend is PHP if that matters. But there might be middle layer between it and database (e.g. java service), so I'm not sure where the query is being constructed.
E.g. following search query works as expected:
test' AND ROWNUM <= 5 ORDER BY 6--
EDIT-FROM-HERE:
Ok after help from comments, following query works:
test' UNION ALL SELECT null,null,null,null,null,null FROM dual--
(I was missing FROM dual part. Thank you #kordirko very much!)
This query adds one empty record in the output table (it is visually visible), so I'm definitely on the right track!
Now following line also works:
test' UNION ALL SELECT null,null,null,n't',null,null FROM dual--
I correctly identified 4th column and now it displays uppercase(?) letter T where I expected it to appear. So far so good. But it gives error when I input any string longer than 1 char! So following gives an error:
test' UNION ALL SELECT null,null,null,n'test',null,null FROM dual--
I'm no expert in SQL injection, and especially ORACLE (though have experience with MsSql).
I think the problem is something unicode-ansi-whateverencoding-related. For other rows (selected by original query before my UNION ALL SELECT addition) the 4th column gives multi-character normal strings. But when I try to inject desired string, it only works if it's one character, and also misteriously displays it in uppercase. I think this must be some encoding problem. I just discovered I needed n prefix for unicode string after 1 hour of searching and struggling. Maybe some Oracle gurus can quickly spot what mistake do I have in my query?

ORA-00907 when quering from my Java application but works fine in SQL Developer

My query that I put into a prepared statement is:
select *
from ( select seq, audit_ts, message_type
from log2
where 1 = 1
and message_type in ('SOURCE', 'DEST')
order by seq desc )
where ROWNUM <= ?
When I run the query in my application, I get:
java.sql.SQLSyntaxErrorException: ORA-00907: missing right parenthesis
EDIT: Here is the java executing the query. I am trying to return a set of search results, so the prefix contains the SELECT statement and then I can have any number of suffixes (in this excerpt "AUDIT_LOG_SEARCH2") which are the parameterized WHERE clauses based on the user search:
StringBuffer query = new StringBuffer(300);
query.append(dbAdapter.getQuery("AUDIT_LOG_ENTRY_PREFIX"));
query.append(dbAdapter.getQuery("AUDIT_LOG_SEARCH2"));
// Insert parameters to complete the sql prepared statement
PreparedStatement ps = _dbConn.prepareStatement(query.toString());
ResultSet rs = ps.executeQuery();
But the query runs fine when I run it separately in SQL Developer. The query was originally created for Postgres, then updated for Oracle. Any tips?
You need to set the variables into the preparedStatement before executing.
PreparedStatement ps = _dbConn.prepareStatement(query.toString());
ps.setInt(1, 10);
Please post what query.toString() gives you if that doesn't work. Not query, but query.toString()
What are you doing in your:
// Insert parameters to complete the sql prepared statement
Are you using correctly the methods ps.setString... or whatever? Or are you just replacing the question marks? the second might be corrupting your query.
Based on #AlexPoole and #EdGibbs comments, I decided to add a bunch more debug statements. It turns out the method was being recursively called with a different sql "suffix" later on in the program if certain conditions were met. The suffix was not updated with the necessary parenthesis for the new ROWNUM wrapping the statement. So although the ORA-00907 can be thrown for many different formatting problems, it was in fact a right parenthesis that was causing me problems :P
The prefix and suffix seems like a weird pattern in this code base for creating sql queries. I'm thinking of getting rid of this and refactoring so queries don't have to be built like that. Any advice??
So for anyone else who runs into this Oracle error, I would suggest logging the sql statement you are generating and play around with it in SQL Developer. If it works in there, but not in your application, your code is probably doing something funky :P

Crystal Reports Issue turning a string into a number

I'm having one of those throw the computer out the window days.
I am working on a problem involving Crystal Reports (Version 10) and an Oracle Database (11g).
I am taking a view from the database that returns a string (varcahr2(50)) which is actually a number, when a basic SELECT * query is run on this view I get the number back in the format 000000000000100.00.
When this view is then used in Crystal Reports I can view the field data, but I can't sum the data as it is not a number.
I began, by attempting to using ToNumber on the field, to which Crystal's response was that the string was not numeric text. Ok fair enough, I went back to the view and ran TO_NUMBER, when this was then used in crystal it did not return any results. I also attempted to run TO_CHAR on the view so that I could hopefully import the field as text and then perform a ToNumber, yet the same as with the TO_NUMBER no records were displayed.
I've started new reports, I've started new views. No avail.
This seems to have something to do with how I am retrieving the data for the view.
In simplistic terms I'm pulling data from a table looking at two fields a Foreign Key and a Value field.
SELECT PRIMARY_KEY,
NVL(MAX(DECODE(FOREIGN_KEY, FOREIGN_KEY_OF_VALUE_I_NEED, VALUE_FIELD)), 0)
FROM MY_TABLE
GROUP BY PRIMARY_KEY
When I attempted to put modify the result using TO_NUMBER or TO_CHAR I have used it around the VALUE_FIELD itself and the entire expression, wither way works when the run in a SQL statement. However any TO_NUMBER or TO_CHAR modification to the statement returns no results in Crystal Reports when the view is used.
This whole problem smacks of something that is a tick box or equivalent that I have overlooked.
Any suggestions of how to solve this issue or where I could go to look for an answer would be greatly appreciated.
I ran this query in SQL Developer:
SELECT xxx, to_number(xxx) yyy
FROM (
SELECT '000000000000100.00' XXX FROM DUAL
)
Which resulted in:
XXX YYY
000000000000100.00 100
If your field is truly numeric, you could create a SQL Expression field to do the conversion:
-- {%NUMBER_FIELD}
TO_NUMBER(TABLE.VALUE_FIELD)
This turned out to be an issue with how Crystal Reports deals with queries from a database. All I needed to do was contain my SQL statement within another Select Statement and on this instance of the column apply the TO_NUMBER so that Crystal Reports would recognize the column values as numbers.
Hopefully this helps someone out, as this was a terrible waste of an afternoon.

Resources