"If you can live with the newly set-up DB, it would be the easiest."

I haven't done anything yet, all 64bit testing has been done locally to see
first what happens.

So I try and rebuild live then and we see what happens, I load with pool and
then just call rebuild, is that it?


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

> On Sun, Oct 02, 2011 at 08:33:26PM +0700, Henrik Sarvell wrote:
> > 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?
>
> Indeed. This indicates that an DB index is out of order, for whatever
> reason. Don't know how this could happen, perhaps by some non-synced
> access. I haven't seen this error in the wild before, but it is issued
> by 'chkTree'. It could be repaired by 'rebuild'.
>
> If you can live with the newly set-up DB, it would be the easiest.
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to