[Zope] Question about possible Data.fs corruption

[Ira Sher]

Dieter,
This is the traceback I always get from adding this particular object 
and then going to view the site homepage:
Traceback (innermost last):
   Module ZPublisher.Publish, line 98, in publish
   Module ZPublisher.mapply, line 88, in mapply
   Module ZPublisher.Publish, line 39, in call_object
   Module OFS.DTMLDocument, line 126, in __call__
   Module DocumentTemplate.DT_String, line 474, in __call__
   Module DocumentTemplate.DT_In, line 602, in renderwb
   Module DocumentTemplate.DT_Let, line 75, in render
   Module DocumentTemplate.DT_Util, line 201, in eval
    - __traceback_info__: data_record_id_
   Module <string>, line 1, in <expression>
   Module Products.ZCatalog.ZCatalog, line 562, in getobject
   Module OFS.Traversable, line 106, in unrestrictedTraverse
    - __traceback_info__: (['105586758764', 'Neela Vaswani', 'Authors'], 
'')
IndexError: string index out of range

Based on feedback I've been getting here, I'm definitely not 
concentrating on data corruption anymore...any ideas about where best 
to place my attentions?
thanks for your thoughts,
ira

On Mar 5, 2004, at 4:39 PM, Dieter Maurer wrote:

> Ira Sher wrote at 2004-3-3 17:58 -0500:
>> ...
>> If a certain kind of object (a "reader's guide") is added to the
>> database, it breaks the site as soon as a person tries to view the new
>> object. We have to restart from a previous version of Data.fs (running
>> Zope 2.5.1, python 2.1, on Debian). I have a copy of the site on an OS
>> 10.3 box with python 2.3 and Zope 2.6.4rc2--on this, the Zope server
>> doesn't come down entirely, but does throw this error when I try to 
>> nav
>> to the index page after an update: File /.../Traversable.py, line 106,
>> in unrestrictedTraverse (Object: Zope) (Info: (['105586758764', 'Neela
>> Vaswani', 'Authors'], '')) IndexError: string index out of range
>
> You should look at the traceback, post it if necessary
> together with a few lines of source code refered to in the
> last traceback entry.
>
>> Thinking this could be a Data.fs corruption issue,
>
> This is very unlikely.
>
> -- 
> Dieter
>