SQLite & ODBC

[Eric Pearson]

Has anybody here used SQLite with SQL Tools or straight ODBC? Can you recommend a stable driver?

-- Eric Pearson, Perfect Sync, Inc.

[Mark Strickland]

Saw one

I saw one and I tested it with SQL Tools. I cannot verify anything about the stability but it did work with my limited test (mostly just SELECTs).

http://www.ch-werner.de/sqliteodbc/

It does not appear many exist.

[Robert DeBolt]

This is the ODBC driver linked-to from the Sqlite CVSTrac page. I have used an older version, not under SQL Tools though, and had no problems with it. It is apparently being expanded to use the newer Sqlite features.

When I attempted to install it under XP/Pro, however, it refused due to a "Could not write to registry" error. This is a documented flaw in some XP installations. I found the fix on the internet and documented it here, (see my last post). If the driver install works on your computer, don't apply the fix.

Note: The fix applies to XP, not to the odbc driver.

[james klutho]

Just a note. A read somewhere that this SQLite ODBC driver has SQLite embedded in the driver (because SQLite is small) so it does not strictly make a connection to a database engine like other ODBC drivers. I would imagine this simplifies the driver and makes it more reliable. Thought that was interesting.

Jim

[Paul Franks]

Seems to me this is like putting a saddle on a cat. SQLite is small, efficient, and made to be embedded. ODBC is huge and inefficient, a lowest common denominator interface.

I suppose there's a reason for this to exist, but I can't think of a good one.

[Michael Mattias]

I suppose there's a reason for [ODBC] to exist, but I can't think of a good one.

But you DID think of a good reason:

a lowest common denominator interface.

Code written using the ODBC interface works on ANY DBMS with an ODBC interface.

Code written for MySql works only on a MySql database.

MCM

[John Strasser]

Here's another reason

Hi Folks,

I'm new here and jumping in (and thanks to Eric for starting this thread - going above and beyond for a vendor - get's my loyalty).

Let's pretend you've got a system that can be used either in a desktop environment or in a client server environment. While SQLITE doesn't support everything that mysql (or other) does - you can still get a good chunk of what you need out of it.

So now you only have to develop for one interface. Makes my job easier.

John Strasser

[Paul Franks]

Putting words in my mouth, MCM. By this, I meant this particular ODBC driver, not ODBC in general. I can't think of a good reason for this particular, peculiar marriage.

[Eric Pearson]

How about "My program needs to connect to various databases, including SQLite"?

"I want to connect to a SQLite database using familiar tools and techniques"?

"I want to use PowerBASIC to connect to a SQLite database without inventing my own CLI"?

-- Eric

[Michael Mattias]

Developing for one specific interface makes sense if you are developing an 'in house' application.

Remember our poll in which we asked if you were primarily developing "as an employee?" Enough answered "yes" to show this is common enough that restricting yourself to 'one interface' can make a lot of sense.

And speaking of developing a database application for one specific interface.... I have had zero (none) replies to my offer to pay for a little help with the Oracle(tm) Client interface. If you have some of that expertise for sale, please check out the complete description at http://www.powerbasic.com/support/pb...ad.php?t=35202

MCM
[email protected]

[Paul Franks]

I guess I'm just not getting through. The point is that SQLite is a small, elegant DBMS specifically designed to be embedded in applications. It was never meant to be "saddled" with a huge, cumbersome interface that "outweighs" it by at least 10X.

As to your Oracle request, I have considerable expertise from the past in Oracle's client-side interfaces, including PRO*C, OCI, OO4O, and ADO, but not with PB. I just test compiled (using msvc) a couple of Oracle's OCI examples, and (using VB) one of the OO4O examples. They still work fine. I think you would probably find ADO to be the best way to go for PB, since you can easily generate the PB includes for ADO, and there are many ADO examples on these forums.

Problem is, we just don't use those interfaces on the client side anymore, since all new development uses browser interfaces, with the DB interface layer being server-side jdbc. Most of the old apps were PowerBuilder, but the cost of maintaining hundreds of PowerBuiler and SQL*NET installations was just too much. Browser interfaces are now fully accepted, and nearly as interactive as the legacy apps, and far easier to maintain.