Well, I noticed what was the culprit. It turned out that portal_catalog turned into a 'tumor'. When I export the catalog it results in a 195Mb file while a few days earlier it was only a few Mbs. For some reason it suddenly grew many times larger than all my content together while hardly any new content was added. Reindexing took ages. About 1000+x longer than normal (= 70seconds). Now it took almost an hour to reindex my content. So then I decided to tried I cleared all indexes. I then tried to let it recreate the indexes (Find tab) but that took ages too. In fact it never finished (I stopped it eventually). So that didn't work. Then I got a backup from a few days old. I exported all my content from the tumorous database and imported it into the backup version (after first removing the existing content). Then I let it reindex the portal_catalog in the backup version and then things were back to normal again. It took about 70seconds to reindex and the database was about 45Mb. I have no idea why the catalog suddenly got into this state and why it took about 2 minutes to save plone content (reindexing the object) and why it took one hour for a full reindex. Right now my database is ok again but this really freaks me out!!! At that point I realized again how much of a black box the zope database actually is and I really keep my fingers crossed that nothing more serious will happen. Danny "Dieter Maurer" <dieter@handshake.de> wrote in message news:16546.36012.687963.233027@gargle.gargle.HOWL...
Asad Habib wrote at 2004-5-12 10:32 -0400:
Hello, I am trying to add a record to a MySQL database using a Z SQL method. The Z SQL method works fine and I have tested it by itself. Also, when called from a DTML method the Z SQL method adds the record to the database but Zope returns the following error: ... * Module Shared.DC.ZRDB.TM, line 63, in abort * Module Products.ZMySQLDA.db, line 328, in _abort
NotSupportedError: (1196, "Warning: Some non-transactional changed tables couldn't be rolled back")
This is not mysterious at all:
The standard MySQL tables do not support transactions (there are "inno"db tables that do).
Your request was aborted and Zope wanted to tell MySQL to rollback the transaction (and undo the changes done in this request). This is not possible (with standard tables). You get informed about this failure.
There is a way to suppress this error report. I think (though I am not sure) that prefixing the connect string with "-" does this. Of course, MySQL does not learn aborts by this. It is just that the problem report is suppressed.
The cleaner way is to use transactional tables or a different database system....
-- Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )