get_data is a ZSQL method that selects some data from a PostgreSQL database table and has a "brain" to help format some of the columns.

OK, this starts to help, so if I set a new key in the REQUEST object I'm forcing a write to the ZODB, correct?

No... REQUEST is a transient per-thread object that isn't stored in the ZODB.

I do not use any "manage" methods to add Zope objects at all. In my application the user does not create any new Zope objects whatsoever. The only data saved is to the the PostgreSQL database. There are Python objects created within external methods but their scope is local to the methods they are used in. On top of this there are no

Are you sure? I'd check those external methods over and over again. If something assigns something to self, or any other persistent object in the EM, e.g. "self.foo = ' bar'", it does a ZODB write at commit time.

session management issues: all pages contain their state using hidden form elements and communicate required state via parameters on the request URL. So in my case I really do not think that there is a need to write to the ZODB. I'd like to be able to freeze the ZODB for the production version. Is it possible to turn off all these implicit writes somehow without breaking the whole framework?

There is an option to FileStorage which makes it read-only, but using it requires the addition of a custom_zodb.py file in your Zope dir or Zope source changes. I don't think this is necessary.

I know this may not be the intended usage that Zope was designed for but the framework is so powerful even without the distributed content management capabilities that I'm sure there must be a safe way to use it in the above manner (i.e. as a straightforward web application server against a backend SQL database)

Sure...

-----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com] Sent: Thursday, March 22, 2001 12:29 PM To: Egilmez, Kaan Cc: zope@zope.org Subject: Re: [Support] [ZOPE Collector] Zope Question entry: Problems using Internet Explorer 5.5 as client brow

...

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.