There's a script called debugzope, that sounds like a debugger. But in real life you can examine the whole ZODB with it. You can even make changes to the ZODB or ZEO. All in all quite handy if you have to correct a few objects in the database, also on a live system.

$ bin/debugzope

Now the variable root becomes your DB's root. All configuration should be taken from the live system in which context it was started.

>>> root
zope.app.folder.folder.Folder object at 0x01C31C70

You can do any changes (and anything) using the usual python commands. The whole Zope infrastructure is in place.

Don't forget to commit when you are ready:

>>> import transaction
>>> transaction.commit()

Otherwise all changes will be reverted on exit!

debugzope(.bat) is usually available if you use the old zopeskel style deployment. The next task is to figure out how to do this with a buildout based deployment.

Who said that Google Docs and Spreadsheets is not working with a nokia mobile?
OK - it's not pleasure, but at least I can see what I wrote after some hacking.

This is the spreadsheet. Read only, the guys check the browser. At least I can see something.

This is the Docs. It is almost working! Click on the tabs is working:


Trying to login through docs.google.com results in:
Adding /?browserok=true at the end of the URL does not help too much. The document list is empty:

Stay tuned for more.

That was done using a nokia E61, SW: 3.0633.09.04, with the stock-builtin browser.

Just bought a nokia E61 to play around.
Tried to update the firmware in it. The nokia software updater did not even start up.
The error message was: "Network connection lost. Check your network connection or wheter a firewall is prventing the application from working properly".
Nope, no firewall problem. Internet explorer was "working offline". Thanks Bill.

Project home is now z3c.zodbtracing on svn.zope.org.
Read more here: http://svn.zope.org/z3c.zodbtracing/trunk/src/z3c/zodbtracing/
Performance can be an issue if using this storage, but that's not for production, just for debugging so don't come whining.

Sometimes happens that you put a security proxied object into a persistent object's property. Then on transaction commit you get the error:
UnpickleableError: Cannot pickle objects
Now you can search al your code and guess where you set that property.
That can be solved much simpler:
modify ZODB/serialize.py temporarly as follows:

def _dump(self, classmeta, state):
# To reuse the existing cStringIO object, we must reset
# the file position to 0 and truncate the file after the
# new pickle is written.
self._file.seek(0)
self._p.clear_memo()
self._p.dump(classmeta)
try:
self._p.dump(state)
except:
#your favorite debugger's break command

self._file.truncate()
return self._file.getvalue()

And voila, classmeta is the class concerned, state is a dict holding the state. From these values it's piece of cake.

Put a bookmark into your browser's toolbar that points to http://localhost:8080/++etc++process/servercontrol.html?restart=1
That simple it is.

The questions "how-to check the structure of ZODB", "what is stored in the ZODB" pops up here and there.
The answer is: http://svn.zope.org/z3c.zodbbrowser/
This is a wxPython package running independently of the Z3 app server. In fact shut it down before trying to start the ZODB debugger.