Announcement

Collapse
No announcement yet.

SQLite & ODBC

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Paul Franks
    replied
    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.
    Last edited by Paul Franks; 20 Oct 2007, 01:32 PM.

    Leave a comment:


  • Michael Mattias
    replied
    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]

    Leave a comment:


  • Eric Pearson
    replied
    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

    Leave a comment:


  • Paul Franks
    replied
    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.

    Leave a comment:


  • John Strasser
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Paul Franks
    replied
    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.

    Leave a comment:


  • james klutho
    replied
    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

    Leave a comment:


  • Robert DeBolt
    replied
    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.

    Leave a comment:


  • Mark Strickland
    replied
    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).



    It does not appear many exist.

    Leave a comment:


  • Eric Pearson
    started a topic SQLite & ODBC

    SQLite & ODBC

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

    -- Eric Pearson, Perfect Sync, Inc.
Working...
X