Closed alsha closed 9 years ago
The algorithm that log4jdbc uses simply finds question marks in the SQL in order and replaces them according to the bind parameter index. It really is not perfect at all and can break down sometimes as you found. I see early in your SQL you have question marks embedded in strings. That's probably what is throwing it off. Unfortunately there is not a good solution to the problem without a complete parsing of the SQL which is beyond the scope of what log4jdbc can do at this time. One way you might be able to work around the problem is to modify your SQL by using escape sequences to specify the question marks embedded in the strings instead of using actual question marks. There may be a simple JDBC escape sequence that could be used too.
Yes, you are right - question marks in string literals are the reason for this misbehaviour. I understand, that fixing that is not a trivial task, I will try to work around it using your suggestion. Thank you!
Log-file output below shows the same SQL two times: not interpolated and interpolated. The second one is only partially interpolated, some parameters are set in wrong positions, e.g. here:
VS_FAHRZEUG.ID in (5367,5368,5402,5154,5144,5156,5322,5343,5158,1,0,0,1,0,1)
1,0,0,1,0,1 at the end is completely wrong. The parameter list is obviously somehow shifted starting from this point.
Here it is: