Announcement

Collapse

New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less

SQLite & ODBC

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

  • SQLite & ODBC

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

    -- Eric Pearson, Perfect Sync, Inc.
    "Not my circus, not my monkeys."

  • #2
    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.
    Mark Strickland, CISSP, CEH
    SimplyBASICsecurity.com

    Comment


    • #3
      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.
      Regards,
      Bob

      Comment


      • #4
        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

        Comment


        • #5
          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.
          --pdf

          Comment


          • #6
            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
            Michael Mattias
            Tal Systems Inc. (retired)
            Racine WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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
              John,
              --------------------------------
              John Strasser
              Phone: 480 - 273 - 8798

              Comment


              • #8
                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.
                --pdf

                Comment


                • #9
                  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
                  "Not my circus, not my monkeys."

                  Comment


                  • #10
                    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]
                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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.
                      --pdf

                      Comment

                      Working...
                      X