Hey Bryan, Thanks for your help. Yes I am using hibernate and I'm fairly certain that it does have something do with what is happening at the hibernate level as I tried updating to the later version of hibernate 3.5.1-Final and ran into a very different error but the issue with prepared statement seemed to go away. Ironically with this later version of hibernate the issue seems to be tied to inserting into the database. Anyhow, that got me thinking about the driver class I'm using and its compatibility to JPA and hibernate. Currently I'm using
hibernate.connection.driver_class=org.apache.derby.jdbc.EmbeddedDriver Would you happen to know if that is correct? and if it would change based on whether I was using JPA 2.0 versus JPA 1.0? Thanks again, Paul On May 25, 2010, at 9:50 PM, Bryan Pendleton wrote: > This part: > >> where product0_.lid=? and product0_.userVersion=? fetch first 2 rows > > seems to match this part: > >> cq.where(cb.and(cb.equal(lidAttr, lid), cb.equal(userVersionAttr, >> userVersion))); > > pretty closely, so it's hard to imagine why your O/R tool thought it > needed to set 3 parameters in the query. > > Unless it somehow thought it was trying to set the "first 2 rows" part? That > is, > did it think it had prepared "fetch first ? rows" and was trying to set the 2? > > You may need to ask in a forum that covers your O/R tool, to get some > suggestions about how to understand its query generation behaviors. > Did you say you were using Hibernate? > > Regarding whether Derby is processing the statement twice, I think that > the log is just a bit hard to read: the statement is listed twice, > but once is a "begin compiling" trace, and once is an "end compiling" trace. > > So, I'm afraid I don't have any breakthrough answers for you, but hopefully > you're armed with more information to ask a more specific question to the > providers of the O/R tool. > > thanks, > > bryan
