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-01 15:32:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!ppp-1-144.cvx6.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Call for review: Database API for the GNADE Project Date: Tue, 1 Jan 2002 22:55:50 -0000 Message-ID: References: <3C2E334F.EF4C534@snafu.de> <3C318524.98C9035A@snafu.de> NNTP-Posting-Host: ppp-1-144.cvx6.telinco.net (212.1.156.144) X-Trace: fu-berlin.de 1009927927 24433194 212.1.156.144 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:18423 Date: 2002-01-01T22:55:50+00:00 List-Id: "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. 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?). 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 must admit, I would like a way -- even if it were a bit yukky -- to add datatypes beyond the standard SQL 92 canon. 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). -- Happy New Year, Nick Roberts