Endian-ness of wlk2sqlite

[jfiddler]

Glancing at the source code for wlk2sqlite, it doesn't appear to
detect whether the wlk file is BE or LE. So, which does it expect? I
think I'm going to move, for a little while, from my SlugOS/BE system
to an atom-based box. Will I need to convert the archives with
arc_be2le first?

I assume that sqlite archives are endian-neutral, and that once the
conversion has been done, the archive can then move betwen BE & LE
machines transparently. True?

Thanks!

[Mark S. Teel]

See below.

jfiddler wrote:
> Glancing at the source code for wlk2sqlite, it doesn't appear to
> detect whether the wlk file is BE or LE. So, which does it expect?

Native endianess - the endianess of the system it is running on.

> I
> think I'm going to move, for a little while, from my SlugOS/BE system
> to an atom-based box. Will I need to convert the archives with
> arc_be2le first?
>

Yep

> I assume that sqlite archives are endian-neutral, and that once the
> conversion has been done, the archive can then move betwen BE & LE
> machines transparently. True?
>

False. There are apparently components of the SQLite database files
which are endian-aware. But, you can dump the database out in SQL format
and then inport it into the new database location.
> Thanks!
> >
>

[Tom Keffer]

I'm sorry to hear that sqlite is not endian-neutral. Their website
explicitly states:

"The SQLite file format is cross-platform. A database file written
on
one machine can be copied to and used on a different machine with
a different architecture. Big-endian or little-endian, 32-bit or
64-bit
does not matter. All machines use the same file format. "

Are you saying that your experience is different? That would be
unfortunate (and probably a bug!)

Cheers,

-tk

[Mark S. Teel]

It is unfortunate but true. I converted my WLK to sqlite on a 64-bit
Intel platform and tried to use it on my 32-bit slug (ARM) and although
the records were there, the values were wildly wrong. Maybe the sqlite3
version for Debian etch is old - seems it was 3.3.9 or somesuch - my
kubuntu is at 3.5.9...

Maybe it was just a library version mismatch. But it is the same result.

Mark

[jfiddler]

In looking around a bit, I found one reference that said sqlite has
been endian-independent since 2.6.3. However, I can't find anything
that says exactly what that means. Maybe, by endian-independent, they
mean that the database (keys, tables, etc.) is readable, and that text
works fine, but maybe it doesn't define (or translate) a 32-bit
integer between BE and LE. That sounds like the behavior that you're
seeing, Mark.

If that's the case, I guess to move the sqlite archive from one to the
other, one will first need to export on the machine that wrote the
archive, then import on the new machine. At least it wouldn't require
a wview-specific utility, but it sure would be nicer if it just moved
transparently.

jerry