Unfortunately I managed to accidentally delete the local copy 32bit I had of
the DB after the conversion was finished :(

However, when I run it on the live database which the copy is an older
snapshot of I get this:

{2L} (302 . {P-D}) tag +ArticleTag {1}
{2L} (302 . {P-;}) article +ArticleTag {1}
{2L} (302 . {P-H}) user +ArticleTag {1}
{5} (306 . {N-4}) tag +Tag {1}
[vr_db_check.l:3] {N-4K} -- Bad sequence
? (show '{N-4K})
{N-4K} (NIL ("haskell" NIL . {8-2y}) ("iPhone" {N-23} . {8-u}) ("ibm" NIL .
{8-2F}) ("im" NIL . {8-2B}))
-> {N-4K}
?

Could this be the culprit?


On Sun, Oct 2, 2011 at 3:21 PM, Alexander Burger <a...@software-lab.de>wrote:

> Hi Henrik,
>
> > I just tried to run vizreader (from scratch) with the 64bit version and I
> > did not experience any problems (as opposed to with early versions of the
> > 64bit version).
>
> Great. That's good news :)
>
>
> > So I thought I should try and run with a complete converted 32 -> 64bit
> > database.
> > ...
> > [/opt/resources/rss-reader/convert.l:8] DB read: Success
> > ?
> >
> > Good or not?
>
> This doesn't look good :(
>
> It is an I/O (read) error, despite the misleading error message. It
> seems it tries to access a non-existing object, or out-of-range database
> file.
>
>
> The reason is hard to tell without a direct inspection of the DB. I
> don't think it has to do with concrete E/R issues, because the
> conversion 32->64 runs on a lower level, directly following the links
> between objects, and observing only a few E/R rules heuristically.
>
>
> Could it be that already the 32-bit DB was not consistent? I remember we
> talked about several problems in the beginning. What happens if you run
>
>   : (load "lib/too.l")
>
>   : (dbCheck)
>
> on the 32-bit system? It should print diagnostics of the form
>
>   1 4 (5282 . 5282)
>   2 1 (18591 . 18591)
>   3 1 (272 . 269)
>   4 1 (28254 . 28254)
>   5 1 (14243 . 8815)
>   ...
>
> iterating all DB files in the first column, followed by lines like
>
>   {obj1} (1 . {obj2}) var +Cls {1}
>   ...
>
> for each index. If something looks wrong, a hard error ("!? ..") is
> issued, or a warning like (dbfCheck Class) for suspicious DB-models, or
> (dangling {obj} ..) for missing indexes is printed.
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to