Thanks for responding so quickly:

No problem!

(1) I don't think I'm writing to the ZODB explicitly, the DTML documents, that generate this error, call a number of ZSQL methods that read (no inserts or updates are involved) data which is then presented in tables. I'm not sure why the transaction mechanism is involved with database reads, although I do see an increase in the Data.fs file size so something is being written. Maybe you could point me to some info that explains when and why writes occur to the ZODB. This behavior has never

A write occurs any time __setattr__ is called on an object instance, or if an attribute is set on an object named _p_changed and it's set to 1 (e.g. self._p_changed = 1). You can't use __setattr__ directly from DTML, but if the DTML method calls an external method or a method of an object built-in to Zope, any of these things can write to the ZODB directly. In practice, this generally occurs when adding DTML documents (manage_addDTMLDocument(...)), DTML Methods (manage_addDTMLMethod(...)), Folders, custom object instances, etc. from DTML.

occurred on the localhost connection where I'm using Netscape as the client browser, nor has it ever occurred on a remote connection when the browser was other than IE 5.5. I'm using

This is very odd. I have no explanation for this.

ZPoPyDA to connect to PostgreSQL. The only other interesting thing I'm doing is to set certain variables in the REQUEST based upon each row coming back from the query. These variables are then used to modify the layout for that row:

<dtml-in get_data> <dtml-if some_criteria> <dtml-call "REQUEST.set(row_prop,'style1')"> <dtml-else> <dtml-call "REQUEST.set(row_prop,'style2')"> </dtml-if> <tr> <td class="&dtml-row_prop;"><dtml-var first_col></td> ... <td class="style3"><dtml-var last_col></td> </tr> </dtml-in>

What does get_data do? The behavior of any dtml-call, dtml-in, dtml-var, etc. can cause writes based on the method they're calling, iterating over, rendering, etc. If your ZODB is growing, something is getting added.

(2) I get the same behavior when I serve through Apache. (not using ZServer behind Apache, just the generated form served directly through Apache)

Sorry, I don't know the answer to this one... it's evidently a bug in IE 5.5.