Hi Roger, OJB uses alsways prepared statements as armin said before, but do you have problems with the prepared statements or with the count of parameter markers (? in the where clause)?
I am asking because we did a lot of experiments with different implementations (or specialisations) of SqlGeneratorDefaultImpl. The first implementation was not using parameter markers at all. So we used prepared statements without any parameter markers, which comes close to dynamic statements (at least in my understanding and I think this is what you need). I would like to post what we did to discuss it here on the mailing list (we are using db2 and could increase the performance 40% in online acces and 50% in batch access). CL -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Montag, 03. März 2008 16:19 To: OJB Users List Subject: Re: Is it possible to force OJB not use execute a prepared statement? Hi Roger, Janssen, Roger wrote: > Hi, > > Just a general question about sql statement execution. > > Is it possible to force OJB not to execute a prepared statement, but > to execute the sql as a regular sql statement? Sorry no! The use of prepared statements is deeply rooted in the OJB core. > > The reason behind this is that we hit some kind of upperbound limit > with MSSQL regarding the maximum allowed number of parameters in a > prepared statement. Some of the statements that are being generated by > OJB are rejected (SQL exceptions are thrown) by MSSQL, because this > upperbound is crossed. Maybe you can find a "hidden property" to adjust the upper bound of maximal PS parameter. regards, Armin > > One solution would be to not use a prepared statement in these cases. > > Greetings, > > Roger Janssen > > ********************************************************************** > *** The information contained in this communication is confidential > and is intended solely for the use of the individual or entity to > whom it is addressed.You should not copy, disclose or distribute this > communication without the authority of iBanx bv. iBanx bv is neither > liable for the proper and complete transmission of the information has > been maintained nor that the communication is free of viruses, > interceptions or interference. > > If you are not the intended recipient of this communication please > return the communication to the sender and delete and destroy all copies. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
