| Hi Riccardo, thanks for your input, it gave me some more information about the EOAdaptor. Here's where I am today: -Everything is working perfectly on the development machine: -10.4.2 client -Xcode2.1 -WO5.3 -MySQL 4.1.13 Debug -ConnectorJ 3.2.0 alpha -Updating a row with accentuated character still crashes (adding is working fine) on the deployment machine: -10.4.2 server -Xcode2.1 (deployment using the command line) -WO5.3 -MySQL 4.1.10a -ConnectorJ 3.2.0 alpha
I've checked all I could as of now, making sure all the same extensions were in /Library/Java/Extensions and even in /Library/WebObjects/Extensions just in case
Here's the setup of each database: Deployment -------- mysql Ver 14.7 Distrib 4.1.10a, for apple-darwin8.0 (powerpc)
Connection id: 1081 Current database: Current user: root@localhost SSL: Not in use Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 4.1.10a Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: utf8 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 UNIX socket: /var/mysql/mysql.sock Uptime: 1 hour 33 min 14 sec --------
Development -------- mysql Ver 14.7 Distrib 4.1.13, for apple-darwin8.1.0 (powerpc) using readline 4.3
Connection id: 9 Current database: Current user: root@localhost SSL: Not in use Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 4.1.13-debug Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: utf8 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 UNIX socket: /tmp/mysql.sock Uptime: 9 hours 18 min 40 sec --------
The connectorJ dictionary is using useUnicode=true&characterEncoding=UTF-8
I have to mention that to get the correct display of accentuated characters (in the BODY column of type BLOB) in either the back office form (when editing a row) or the front office I had to do: alter table news change BODY BODY BLOB; (not sure this one was necessary though) alter table news change BODY BODY TEXT CHARACTER SET utf8; (this one saved the front office)
If I do SELECT ... inside mysql command line, I got: --- 1 |testLocal again était | 4 | true | 2005-08-10 11:16:27 | 2005-08-10 11:37:04 | 275 | 80 | testLocal again était --- in both developpment or deployment. So at least everything displays fine.
Here's the line I got from the adaptor when trying to update a row with accentuated character: Deployment --- evaluateExpression: <com.webobjects.jdbcadaptor.MySQLPlugIn$MySQLExpression: "UPDATE NEWS SET TITLE = ?, BODY = ?, DATE_UPDATED = ? WHERE (ENTRY_PK = ? AND TITLE = ? AND BODY = ? AND AUTHOR_FID = ? AND DATE_POSTED = ? AND SOURCE_FID = ? AND DATE_UPDATED = ? AND CATEGORY_FID = ? AND COMMENTARY_ALLOWED = ?)" withBindings: 1:"test again ~Ntait ~H la fin"(title), 2:"test again ~Ntait ~H la fin"(body), 3:2005-08-10 11:39:31(dateUpdated), 4:287(entryPK), 5:"test again ~Ntait"(title), 6:"test again ~Ntait^M"(body), 7:1(authorFID), 8:2005-08-10 11:11:02(datePosted), 9:80(sourceFID), 10:2005-08-10 11:36:02(dateUpdated), 11:4(categoryFID), 12:true(commentaryAllowed)> --- and this one in development --- evaluateExpression: <com.webobjects.jdbcadaptor.MySQLPlugIn$MySQLExpression: "UPDATE NEWS SET TITLE = ?, BODY = ?, DATE_UPDATED = ? WHERE (ENTRY_PK = ? AND TITLE = ? AND BODY = ? AND AUTHOR_FID = ? AND DATE_POSTED = ? AND SOURCE_FID = ? AND DATE_UPDATED = ? AND CATEGORY_FID = ? AND COMMENTARY_ALLOWED = ?)" withBindings: 1:"testLocal again ~Ntait"(title), 2:"testLocal again ~Ntait"(body), 3:2005-08-10 11:37:04(dateUpdated), 4:275(entryPK), 5:"testLocal again ~Ntait ~H la fin"(title), 6:"testLocal again ~Ntait ~H la fin"(body), 7:1(authorFID), 8:2005-08-10 11:16:27(datePosted), 9:80(sourceFID), 10:2005-08-10 11:19:58(dateUpdated), 11:4(categoryFID), 12:true(commentaryAllowed)> --- It looks pretty much the same!!
but the deployment lead to the following crash: ------- [2005-08-10 11:39:31 CEST] <WorkerThread0> === Rollback Internal Transaction[2005-08-10 11:39:31 CEST] <WorkerThread0> <com.webobjects.appserver._private.WOComponentRequestHandler>: Exception occurred while handling request:com.webobjects.eoaccess.EOGeneralAdaptorException: updateValuesInRowDescribedByQualifier -- com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in database[2005-08-10 11:39:31 CEST] <WorkerThread0> com.webobjects.eoaccess.EOGeneralAdaptorException: updateValuesInRowDescribedByQualifier -- com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in database at com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseContextInformationAdded(EODatabaseContext.java:4685) at com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabaseContext.java:6393) at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:415) at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3223) ... -------
and the development to a success: ------- [2005-08-10 11:37:04 CEST] <WorkerThread11> === Commit Internal Transaction -------
I'm getting lost... If anyone think about something after reading this...
Xavier
Hi guys,
I'm not sure if I can be of any help, but I had simillar problems even if not related to a connector-J upgrade. In the end they where all related to my wrong understanding of how to implement UTF-8 encoding and some ambiguous data in my db. In particular I had thousands of crashes with "can't update row in db" because of a series of null values in date fields. My db had come from openbase first, frontbase after and via a text dump had finally arrived to mysql. You can immagine every one of these has it's own way of treating things so no surprise when I found out that null dates are often different from db to db. Anyway, the connector-J option zeroDateTimeBehavior=convertToNull saved my ....
Further on, a good way to find out what's wrong is an old style test and trial method I did use as well. Turn on adaptor logging adding -EOAdaptorDebugEnabled YES to your executable. Reach the place where the error occurs and note down the sql line that causes the crash. Then access your db via a manual sql client of some sort and try the line. Remove one after the other, all the fields till you get the line working and you'll know who is the culprit. Usually all these errors are caused by some unexpected type casting/coercion/conversion done by java or the db itself. In the end, any value you give in a way and get back in a different way could be a problem and in most cases, you don't need to optimisticly lock ALL the fields of a db.
Finally about special characters... I have no experience with cyrillic as the most strange thing I deal with are the various italian accents, but it took ages before I did really understand how to correctly implement utf8 encoding.
If it can be of any help, my connection string for connector-J is: jdbc:mysql://localhost/dbname?capitalizeTypeNames=true&zeroDateTimeBehavior=convertToNull&useUnicode=true&characterEncoding=UTF-8
I hope anyone of these things can help you fixing your problem...
Regards, Riccardo De Menna
On 9 ago 2005, at 16:45, Müller, Michael wrote:
|