No announcement yet.

Creating DAO Interface for Custom ISAM

  • Filter
  • Time
  • Show
Clear All
new posts

  • Creating DAO Interface for Custom ISAM

    Creating DAO Interface for Custom ISAM

         I have a problem as under :
         01. I am developing a big system which should support ANY database
    at wish of a cusomer ( Say Btrieve,Custom ISAM like TRM etc.). The code is in vb6 and for developement purposes we
    are using DAO for MS ACCESS (DAO 3.51)
         02. I would like to use a custom ISAM like Btrieve/TRM ISAM which gives a dll supporting
    normal read/write/update/delete options on indexes
         03. But the said ISAM does not have a DAO/ODBC interface and
    datafile contains index pages as well (like Btrieve)
         04. I would like to retain code of application programs. The
    application does not define RecordSets directly but get the
               Recordset through a activex dll and thereafter the
    application uses DAO syntax like .movenext .update etc.
         05. Is it possible to connect the custom ISAM/Database DLL to DAO
    engine so that I get a recordset and thereafter
               I will use normal recordset syntax using ISAM dll in the
         I shall be greatful if you can guide me in the matter
         Thanks and Regards
    G. A. Gokhale
    [email protected]


  • #2

    I'm sorry but I don't fully understand your problem. Is this
    project going to be programmed in VB and PB or strickly PB?

    If this is a VB problem we should probably move this to the
    Third Party Fourm.

    The impression I have is that you want to use standard DAO
    syntax for all the Databases that you can possibly open?

    You might want to consider purchasing SQL Tools from PerfectSync
    they offer support for both VB and PB and it works on all ODBC
    Databases. Syntax is alittle different from DAO but very
    easy to learn.

    Eric did I miss anything?

    [This message has been edited by Gregery D Engle (edited October 14, 2001).]
    [email protected]


    • #3
      Hello Gregery,

      My project in fully in VB6 but I can use PB/DLL for any
      database interface. I did not know where to put my query hence
      I have put the same in Windows Section.

      The Database/ISAM manager can be anything MS Access
      / Oracle / Btrieve / TRM or any custom Database at wish of
      Customer. Therefore I am looking at various options and create
      a parameterised system.

      Even Networking Operating System can be anything like
      Novell Netware (Which I prefer) or Windows NT (or later on Linux)

      Only front end (for the time being) is windows but
      I have a personal wish to make it portable to linux using some
      emulator like WINE ( though this can wait)

      The ISAM manager may or may not provide any DAO or ODBC
      interface e.g. TRM does not provide DAO/ODBC interface and I
      cannot shift to PB fully due to size of the project. Therefore
      using SQL Tools or any ODBC manager may not be possible. Secondly
      I wish to have indexed access to the concerned database due
      to speed requirements on a large database (which I fear ODBC
      may not provide adequete performance). My principle data file
      is likely to be 2-3 GB with 3 million records.

      I am looking forward to write my own OCX/Control which
      will embed Database DLL but give Recordset to the application
      program so that if database changes then my application does not
      change but only backend OCX changes.

      I may be trying too much but in this manner I can retain
      single application logic and coding standard and hence
      request for help.

      Anyway Thanks and Regards for the response

      G. A. Gokhale



      • #4
        Gopal --

        I think you are correct... SQL Tools would not be a "universal" solution because some of the databases that you must use do not support ODBC.

        That being said, I doubt that a universal solution exists.

        > I am developing a big system which should
        > support ANY database at wish of a cusomer

        That's a bit like saying you need an employee that speaks any language.

        Unless you are prepared to write a program that will open and analyze the structure of a database of an unknown type, and then interface to it, I can't imagine how a program like that would work. That would be a massive project -- I'd guess dozens or hundreds of man-years -- and that would make it so expensive that your customers would not be able to afford it.

        Investigate the structure of Access databases and you'll begin to see what I mean. Not to mention the fact that major databases like SQL Server and Oracle are not "files" that programs can access. They are treated as "an area on the hard driver" and can be accessed only through the approved interfaces, such as ODBC.

        If I were attacking this project, I would look at a "modular" solution. ODBC is the world's most widely-supported database standard, so I would use that for as many "popular" databases as possible. There might also be other "groups" of databases that could be handled by single modules. But then you would have to start writing custom modules for the other databases that you need to support.

        > I fear ODBC may not provide adequete performance

        That's a common misconception. Most SQL Tools users report performance that is equal to or better than ADO, DAO, etc.

        Remember, DAO is heavily based on ODBC. (If you don't believe me, try un-installing ODBC drivers and then running a DAO program.) So DAO is an additional layer on top of ODBC. And don't forget the ActiveX layer that DAO requires.

        Getting back to my original point, I think it is extremely unlikely that you will find (or be able to write) a single, one-layer solution that meets your requirements.

        -- Eric Pearson, Perfect Sync Software (creators of SQL Tools)

        Perfect Sync Development Tools
        Perfect Sync Web Site
        Contact Us: mailto:[email protected][email protected]</A>

        [This message has been edited by Eric Pearson (edited October 15, 2001).]
        "Not my circus, not my monkeys."


        • #5
          Hello Eric,

          Thank you for your valuable advice. But the situation or
          preposition of writing own control may not be so much weird
          as it may so appear.

          When I said ANY Database it did not mean so much unknown
          database. Here out in India ( may be in US also) some customers
          are very much cost consious but at the same time need the
          features offered by new technologies. If I may say so I have
          two groups of databases

          01. I am writing a retails banking product as as an upgrade (???)
          to a COBOL/Btrieve/Netware combination (Also written by me).
          Since all operations are online explicit transaction
          processing, Begin/End/Abort transactions at program level
          as well as at Server level is a MUST.

          One type of databases are where DAO/ODBC interface is
          available like MS Access/MS SQL/Oracle but do not provide
          server level Transaction Processing on Novell Netware but
          provide same on NT Server as Database Server(As I understand)

          If an existing customer chooses NT server then he will have
          to forego the existing investments on Novell which may not be

          02. So he has to choose a database like Btrieve which is existing
          database but for windows interface he may have to spend money
          or like TRM which is an excellent FREE tool but does not
          provide ODBC/DAO and also No Transaction Proceesing (which
          I may be able to implement from my project design point of
          view). On this count I need to write application in such
          a manner that I should be able to create DAO like interface
          where I can return an object which will have similar methods
          and properties. Although I worked at system level in DOS
          I do not possess sufficient knowledge in windows environment
          and hence I need help. If I do not take this path then I will
          end up in having different code for different database types
          which I fear will sink me.

          Although a very long reply, I have written my problems so
          that may be I will get some pointers/help in this direction

          I respect technical competence of this group hence all the

          Sorry to have bored you all with my problems ...

          Regards and Thanks




          • #6
            I've been down that road of "I'll support anything" so I'll let you in a little secret: that road goes to hell, but it don't come back.

            I am doing something like this now, but I just make it a rule for the user: "May use any database for which you can obtain an ODBC 3.0+ driver." I conveniently check this when the software starts and tell the user "This database is unsuitable for use with this system."

            Besides, if a potential user is too cheap to spring for a couple hundred bucks for a DBMS with an ODBC driver, how much money do you expect him to spend with you?

            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]


            • #7

              I agree with Eric... a universal solution probably does not exist for what you described. However, I think
              you could achieve much of what you want by limiting your database options and the command lists within those

              Any way you approach this, it will require a great deal of time and effort on your part, and only you can be
              the judge of whether or not it is worth that much effort. If you decide it is worth it, then I would proceed
              by identifying the least number of database functions your application would need, and limit your supported
              database products to those where the needed functions can be handled natively or programmatically by your code.

              Once those selections are made, you would essentially need to write a routine that would interpret the DAO-like
              syntax that you plan to use, sending the necessary calls/commands to the desired database tool. In my opinion,
              Eric's SQL-Tools should easily handle any access you need to database managers with ODBC drivers. For other
              data management products (custom ISAMs), your own routines would need to translate between your DAO-like syntax
              and the data manager's interface.

              In any event, it's a very demanding project. I hope you aren't under severe time constraints, as such an
              approach will no doubt require a great deal of testing and debugging. Good luck.

              mailto:[email protected]
              Tsunami Record Manager