× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



My Fellow Midrange Geeks and Geekettes:

One of the features I've put into my project is the ability to incorporate a user-specified WHERE clause into the generated WHERE clauses of my queries, in order to filter the records accessed.

But if the user uses this feature to insert garbage into the WHERE clause (e.g., "WHERE FOO = 'BAR'," with no FOO field in the file), it results in a series of bad JDBC calls that crashes JDBC and the JVM, requiring the user to sign off and sign back on.
Space offset X'00000000' or X'00008000300149F0' is outside current limit
for object <jobname> <user> <jobnum>.

I'd like to be able to catch the bad query before this happens. Is there a way to do this?

It seems, running it in the debugger, that when the query gets executed
rs1 = jdbc_ExecQryCS( conn : %UCS2('Select * '
+ ' from ' + %TRIM(QUALTBL) + ' WHERE ((')
+ %TRIM(WHERECLAUSE1) + %UCS2(') ') + %TRIM(ORWHERE1)
+ %UCS2(') AND (') + %UCS2(%TRIM(ADDLWHERE))
+ %UCS2(') ORDER BY ' + ORDERBY));
(jdbc_ExecQryCS being a UCS2-parameter [so we can process Unicode keyfields], scrollable result set version of jdbc_ExecQry), RS1 comes back as null (0), and an RNX0301,
Java exception received when calling Java method.
appears in the joblog, with
Cause . . . . . : RPG procedure JDBC_EXECQ in program AQUESTVIEW/JDBCR4QV
received Java exception "java.sql.SQLException: [SQL0206] Column FOO not in
specified tables." when calling method "executeQuery" with signature
"(Ljava.lang.String;)Ljava.sql.ResultSet;" in class "java.sql.Statement".

Now assuming I recognize, and respond to, the null result set I get, am I going to have to insert an ExceptionClear somewhere, in order to keep the next call from crashing the JVM? For reference, here is the aforementioned "jdbc_ExecQryCS":
P JDBC_ExecQryCS B export
D JDBC_ExecQryCS PI like(ResultSet)
D conn like(Connection) const
D sql 32767C varying const options(*varsize)
D stmt s like(Statement)
D temp s like(ResultSet)
D rs s like(ResultSet)
/free
jdbc_begin_object_group(50);

monitor;
stmt = createStatement2( conn: 1005: 1007); // 1007 read-only
temp = executeQuery( stmt : new_StringC(sql));
jdbc_end_object_group(temp: rs);
on-error;
jdbc_end_object_group();
return *NULL;
endmon;

return rs;
/end-free
P E
(Not too different from Scott's original jdbc_ExecQry.)

--
JHHL

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.