04.06.2010, 21:22, "Michael Tiernan" <mtiernan@xxxxxxx>: > Ok, here's what I've found out. The problem SEEMS to be related to the > character sequence of [0-9]:[0-9] > > As an example, here's a sequence that works with no problems: > Battery 1 XXXXXXXXX 01/18/2010 10 (Installed 3/10/2010 > 14J25J28) > Battery 2 XXXXXXXXX 11/26/2009 10 (Installed 03/05/2010 > 11J35J10) > > Now, here's a really strange one. Take that same line and change one > character "J" to a colon ":" and we get: > Battery 1 XXXXXXXXX 01/18/2010 10 (Installed 3/10/2010 > 14:25J28) > Battery 2 XXXXXXXXX 11/26/2009 10 (Installed 03/05/2010 > 11J35J10) > > And right after the "Save" option, it changes to this: > Battery 1 XXXXXXXXX 01/18/2010 10 (Installed 3/10/2010 14?) > Battery 2 XXXXXXXXX 11/26/2009 10 (Installed 03/05/2010 > 11J35J10) > > Notice the end of the first row? > > I have to reset my system to do some of these tests again but this helps > narrow down the problem. That's a good research, now I see, what really happens. This semicolon can be interpreted as a part of the so called "prepared statement" syntax (http://php.net/manual/en/pdo.prepare.php), but only when the code requests a library to "cook" the query in a way and to bind the parameters later, at the time of query execution. That is why the error message you see tells about query parameters. But the matter is, that specific function, in which the query fails, does not use this technique, and a semicolon has no special meaning, it is just a part of the text. I have tried the sample above, and the error doesn't reproduce on my system, it is just saved text verbatim. So I guess, it is a bug somewhere between your copies of PHP-PDO and MySQL server. You can verify this by getting a server with a completely different distribution and replacing one component at a time. The best thing would be filing the bug to the package vendor, so we don't see it any more. Thanks for the time you spent on this. -- Denis Ovsienko