a cheep interface to database

From: yos (yocafi_at_yahoo.com)
Date: 07/02/04 

Date: 2 Jul 2004 13:14:35 -0700

Hi all,
I am an Acucobol user, and I have to write a program that stores the
data into
a database. I don't know SQL, and I would prefer not to learn ESQL.
I had been told that I have a couple of choice:
-using Acu4GL, that lets me to write normal Cobol statements (OPEN,
WRITE, START, READ, etc) to interface to a database like Oracle,
Informix, MSSQL, DB2, ODBC, etc
-using DBMaker/DCI that basically allow me to work like with Acu4GL,
but it is
only for DBMaker.

I don't have to interface with a particular database, so the cheaper
solution
will be the best.
As far as I know the DBMaker/DCI solution is the cheaper (and someone
tells me
that's also the faster). I would like to know if some of you have
adopted with
success this solution.

thanks in advance,
yo

Relevant Pages

  • Re: Beginning C# Q
    ... starting out with a network app0lication, you have an awful lot to swallow. ... Designing your database is therefore, not quite the first step, particularly ... Groups table, which defines which Groups users belong to, and a Permissions ... That is why an Interface is called an Interface. ...
    (microsoft.public.dotnet.framework)
  • Re: Transaction Oriented Architecture (TOA)
    ... If one builds the application around the database view, ... The problem solution should not have to know about mechanisms like SQL query construction, optimizations like anticipatory caches, or encoding/decoding of dataset formats. ... Note that the CRUD/USER environments already provide exactly that encapsulation by providing a Data Layer that is isolated from the rest of the application through an interface. ... TOA/TOP proposes the database and its application domain stored procedures are the only persistence mechanism necessary, and that the benefits of a focused, single, data-permeable gateway between application and database far exceed the benefits of O/R mappings--regardless of abstraction--and that its lightweight appearance shouldn't be dismissed as missing heavyweight kick. ...
    (comp.object)
  • Re: Transaction Oriented Architecture (TOA)
    ... I don't think the issue is ignoring the database; it is recognizing that the database is a different subject matter applying different business rules than the problem solution. ... There is nothing to prevent abstracting the database subject matter in a classic OO manner with objects like Schema, Table, Tuple, and Query. ... I'm of the opinion that the more obvious the database (or at least its interface) is the more easily maintainable an application becomes. ... I've nothing against creating frameworks and patterns to facilitate those programming activities, but prefer the concept of a problem domain transaction to language-specific expressions mapping 1:1 with anything physically present in the database. ...
    (comp.object)
  • Re: OOP style
    ... Component classes have all their main logic in a Custom base class ... database access unit if they didn't already start with a full DB layer; ... My latest application started with an extensively designed object model ... Typing in the implementation of the database interface is ...
    (comp.lang.pascal.delphi.misc)
  • Re: OOP/OOD Philosophy
    ... You appear to assume that, in order to isolate the database from the gui, ... the GUI layer uses a specific interface of the business ... This is where you need to place logic against the data structure that ...
    (comp.object)