Okay, earlier this year I figured out that the reason for our binary data problems when retrieving stored files from the database was the use of PreparedStatement. Well, we don’t use it for files, however we do still use it in so many other plaves in our code. We kept getting some recurring errors the most common one being that the placeholders had not been bound with objects before running the statment. Basically, PrepareCall() failed. We stepped through multiple times until we found an example where the error was found and found that in fact, there was no problem with the bound SQL generated by the PreparedStatement. So the error was being thrown for absolutely no reason that we could fathom. So, I did the exact same fix as for the binary data retrieval bugs and it fixed the problem. There seems to be major problems with the PreparedStatement calls and so now we just grab the sql that has been prepared, and then run it directly. For those who don’t remember how this was done, here is some sample code:
PreparedStatement statement = prepareStatement(query, variables, values);
String statementString = statement.toString();
statementString = statementString.substring(statementString.indexOf('-')+1);
return statement.executeQuery(statementString);Just as some notes, prepareStatement() takes the query and binds all the values to the string. The next line gets the value of the PreparedStatement as a string. This will yield something similar to this:
com.mysql.jdbc.ServerPreparedStatement[3] - call impr_linkable_object_find_connected_by_type(2, ‘org.impresario.core’, ‘user’, ‘org.impresario.core’, ‘project’)
As you can see, there is information about the object before you get the sql. The following line strips everything before that first - so that you are left with only the sql call itself which is then executed independently as a string.
Suddenly, we no longer have that annoying problem popping up. 
