Baslinux mailing list

[baslinux AT lists.ibiblio.org]

> > I converted postamt.dbf (327 bytes) to postamt.sql (501 bytes - longer
> > because each record starts with the string INSERT INTO postamt VALUES(
> > to postamt.db (3072 bytes).  The sqlite .db file has long stretches of
> > absolute garbage ^@ at the beginning and end.
>
> This will probably just be padding. Remember this is a binary file, not text
> - and how an editor sees the non-text characters is fairly arbitrary. I
> think nul (i.e. a zero byte) often displays as ^@.

Also random stretches (dozens of lines) in the middle of words.  I think 
this is due to bugs in the original dbf manager.  -trim b got rid of the 
the normal padding, but left the random garbage, some of it in the middle 
of one header definition, or in the middle of words.

Can you explain how to import filename.csv (which includes header info) 
into filename.db?  The csv file created from the dbf with the same 
convertor (viewed with pico) has no random garbage in it to start with.
The 'trim' function is suggested for exporting sql only (which otherwise 
keeps the blank spaces?).

> > I converted my larger dbf file from dbf to db and it grew from 430K to
> > 960K, more than double.  It also has long stretches of caret-atsign
> > in between records.
> >
> > This sort of resembles DNA - long stretches of meaningless repeats.
> > I may experiment with removing them and see what happens.
>
> You can try ... but I suspect it will break the database.  I suspect the
> padding is due to fixed length records, so if you remove it, the database
> will be confused about where the next record begins.

Pico cannot even see the garbage.  I can see it with less.

> Ian

Many thanks,
Sindi