From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,72b10ed43fd78730 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-02 06:29:35 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!unlisys!news.snafu.de!not-for-mail From: Michael Erdmann Newsgroups: comp.lang.ada Subject: Re: Call for review: Database API for the GNADE Project Date: Wed, 02 Jan 2002 15:31:21 +0100 Organization: http://purl.org/NET/michael.erdmann Message-ID: <3C3319B9.80386CE@snafu.de> References: <3C2E334F.EF4C534@snafu.de> <3C318524.98C9035A@snafu.de> NNTP-Posting-Host: tc12-n67-190.de.inter.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.75 [de] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:18447 Date: 2002-01-02T15:31:21+01:00 List-Id: Nick Roberts schrieb: > "Michael Erdmann" wrote in message > news:3C318524.98C9035A@snafu.de... > > > > My preference would be for Module SQL (92). Is your API intended to be > at a > > > level below this? > > > > Please could you clarify this a little bit. The GNADE project already > provides > > and embedded SQL preprocessor, so i am not sure what you realy mean by > > this. > > Simply that the choice I would personally prefer (usually) for > database-access support within Ada programs is Module SQL. I wouldn't mind > in the least if the same macro/pre-processor approach were taken to the SQL > module files, e.g. translating them into the equivalent Ada code. Any how what is Module SQL, do you have link? > Such Ada code would need to have a low-level method of accessing the > database(s); I was wondering if the API you are suggesting is intended for > this purpose (or is it for use directly by application software?). It is intended for application development. The idea is to provide a common interface to access data sources (e.g. Microsoft ADO). In the moment the proposal is just the smalles possible interface which i think which can be supported by most data base products, > The nice thing about Module SQL is that it does separate the SQL bit from > the Ada code (unlike Embedded SQL). This means that you could, for example, > rewrite a module in Ada (e.g. if the data was no longer coming from or going > into a database), and know that (provided it replicated the behaviour of the > module's procedures) the rest of the Ada program will be unaffected. I am still not sure what Module SQL is, but it comes quite near to the idea of MS ADO, that by changing the query you might use a new data source without rewriting the the whole applicaition. > I must admit, I would like a way -- even if it were a bit yukky -- to add > datatypes beyond the standard SQL 92 canon. I think this makes sense because most of the data bases are supporting a wide variaty of data types. I will check on this! > Of course lots of SQL3 features > would be handy, but I get the impression that's an issue (SQL3 has yet to be > convincingly accepted by the mainstream database companies). This is to mutch for the first step! > > > -- > Happy New Year, > Nick Roberts