I have found a bug in ZSQL methods that is describe by this collector item: http://classic.zope.org:8080/Collector/718/view This item was posted over a year ago! The bug is still in the program, so I'm guessing that DC folks are too busy to get to this. The collector item described above describes a weak work-around because the submitter didn't understand how this exception can occur.. Here's how it happens.. If a query is executed twice, the second time beyond the cache time limit. Then the query string is stored in tcache{} twice (two different times) but in cache{} only once. Eventually the cache reaches it's maximum size and entries are expired in reverse time order. The earlier tcache{} entry is encountered and the query in cache{} is deleted. Eventually the later query is also deleted from tcache{}, but the query no longer exists in cache{} and a KeyError is raised. Here's the fix I'm applying. I'm only deleting the cache{} entry if it's time matches the tcache{} entry that is about to be deleted. I couldn't figure out how to post a patch for a pending collector item. Also didn't want to duplicate the pending bug report either. -- lib/python/Shared/DC/DA.py line 392 or so while keys and (len(keys) > max_cache or keys[-1] < t): key=keys[-1] q=tcache[key] del tcache[key] if int(cache[q][0]) == key: del cache[q] del keys[-1] My change is: if int(cache[q][0]) == key: del cache[q] Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements