Error PreparedStatement and Oracle 10g

Question

I have a big problem with INTERMITTENT with an error in Oracle 10g when we call some SQL in a Java web application. We cannot quickly fix or upgrade to 11 g, which seems to be the first “stupid" answer to support the oracle. It works, but I am having problems with this in PreparedStatements in my Java code.

Actual error:

ORA-00600: internal error code, arguments: [kcblasm_1] 

Error: Oracle Bug 12419392

Work around is done

 alter session set "_hash_join_enabled" = FALSE; 

before we run our SQL query. However, traditionally PreparedStatement accepts one 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 it possible just by running a series of sequential PreparedStatements one by one?

Not the best time to get it with Xmas pending and reduced support, etc. etc., so I really hope someone can help. Thanks.

Edit : @jonearles requested the code, so here it is, if used. Probably very specific to our project, but someone might notice a glaring problem causing an error:

 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 

Answer 1

OK The answer to my main question: NO, you cannot create a PreparedStatement like this:

 PreparedStatement stmt = con.prepareSelect("sql statement1; sql statement2;"); 

Running separate statements to temporarily change the session for one bit of SQL did the job, but agreed, it seems, to a terrible as well as an unacceptably slow response. The options seem to be a patch or update, or look at the no_use_hash prompt (which I think will be too slow). Look at the code.