Base: Connecting to SQLite3 .db and Working With it

users
#21

The hsqldb 1.8 documentation ? LO uses the hsqldb 1.8 as the embedded db
engine in LO by default, unless you meant you are setting up a "split"
database using an external hsqldb.jar version > 2 ?

Alex

#22

Alex,

   The manual appears to be the most current, but it refers to backward
compatibility with versions 1.8 and 2.0 with the syntax for an
autoincrementing primary key. I could not care less which hsqldb is used as
long as LO-4.3.5 Base will work with it.

   I'm translating the SQLite schema .sql to the HSQLDB DDL syntax. I'll
check syntax with the hsqldb mail list and ask them how to generate the file
that Base will recognize using the jdbc interface.

Thanks,

Rich

#23

If using HsqlDb then it would be MUCH better to use their proper full
program downloaded from their site as an external back-end.

Tom,

   OK. Guess I need to download, build, and install a 3rd rdbms. That's
do-able. Lots of room on this partition.

   I assume that once the .db file (or whatever extension it uses) is in the
appropriate subdirectory I need only tell Base to connect to it and hope
that it works.

Err, if you do go the Python route then please ignore my earlier post! I
was optimistically assuming that it would be less coding and therefore
easier!!? I hadn't thought about APIs and stuff. Sorry about that :frowning:
Regards from Tom :slight_smile:

   Long ago I wrote a driver in C for a spatial analysis application; it was
quite different from developing an end-user application. I much prefer to
avoid the pain of writing another driver and in Python.

Stay tuned ... updates at 11,

Rich

#24

Hi :slight_smile:
If using HsqlDb then it would be MUCH better to use their proper full
program downloaded from their site as an external back-end. The
in-built back-end has serious flaws which have apparently resulted in
data-loss for quite a few people so it needs frequent back-ups. As an
external back-end it doesn't have all the tweaks and things that Sun
added (and/or took away (such as the ability to update the program))
so it works brilliantly apparently.

Err, if you do go the Python route then please ignore my earlier post!
I was optimistically assuming that it would be less coding and
therefore easier!!? I hadn't thought about APIs and stuff. Sorry
about that :frowning:
Regards from
Tom :slight_smile:

#25

Are you using UTF-8?

Paul,

  Yes.

I don't know much about your problem, but Googling shows there may be a relationship.
See https://www.sqlite.org/c3ref/open.html

  According to that web page, UTF-8 is the default for sqlite3_open() and
sqlite3_open_v2(). In that case, having LANG=en_US.UTF-8 should not be a
reason why Base cannot establish the connection.

Well, yes and no, much to my chagrin, when using the copy command on Ubuntu, I discovered files that would not copy as they used a different encoding in the file name.
They displayed normally do to "naturalization", but when copied to a NTFS formatted disk, refused.

I eventually resolved the problem using "convmv" command.
convmv - converts filenames from one encoding to another.

The nice thing about this command is it does have a test mode and will not change anything until you tell it to.

Hence, a command that runs properly, but cannot recognize a file name.

Another shot in the dark.