Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mejac!orchard.la.locus.com!prodnet.la.locus.com!jfr From: jfr@locus.com (Jon Rosen) Newsgroups: comp.databases Subject: Re: c++ and SQL Message-ID: <25006@oolong.la.locus.com> Date: 4 Jun 91 18:27:56 GMT References: Distribution: comp Organization: Locus Computing Corp, Los Angeles Lines: 59 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Having gone through the process of trying to connect up C++ with an SQL >preprocessor, I would recommend against attempting it unless you have an SQL >preprocessor designed to work with C++. Instead, I have found that the much >more reliable and portable method is to modularize your SQL calls into >straight C functions so that you may use the standard SQL/C preprocessor on >them and later link these with the rest of your C++ code. The other approach >(SQL embedded in C++) will always be a hack to interface with the way one SQL >preprocessor or C++ compiler works. > >#define SOAPBOX_MODE >For this reason, I believe that the SQL standard should not specify a >preprocessing standard on top of some other language, but rather a method of >using SQL that does *not* require a change to the base language that it will >be used with. If that were the standard, then any RDBMS with an SQL interface >that works under (for instance) VAX/VMS would be able to interface with *all* >the languages used on VMS. You would not need a special preprocessor for each >language. >#undef SOAPBOX_MODE EXEC SQL PREPARE REBUTTAL FROM "There are only three ways to introduce SQL capability into a language. First, you can add it directly to the syntax of the language. Second, you can provide a call-level interface. Third, you can provide a preprocessor which converts something that looks like native syntax into actual native syntax and calls to a supplied run-time call-level interface. The argument you give is for a direct call-level interface. The argument against this idea (given by IBM when SQL/DS was released) is that a call-level interface directly available to the user limits the ability of the vendor to enhance the interface in the future or optimize the use of the interface in the future without requiring possible changes to the source code. Using an abstract syntax enhancement which hides much of the internal detail needed to support SQL (such things as placing data and nulls into host variables and the like) makes it much simpler to enhance the interface (i.e., the preprocessor and the call-level run-time routine) without needing to have the user make changes in the program. This was deemed a critical issue. While C programmers may not find it a good argument (although I don't see why, since we all use our own preprocessor to support our programming already), it was essential for COBOL programmers which is the prrimary market IBM is aimed at. My only complaint is that there was (and is) no need to make the underlying call-level interface a magic hidden thing... Ibm could have published it as well as the preprocessor interface and stated that they expressly reserved the right to make major changes in the call-level interface at any time... Using the preprocessor would protect you but using the call-level would allow you to interface easily with languages that didn't have a preprocessor capablity. This they chose not to do so language support is limited to use in languages that have an SQL preprocessor... By the way, no other vendor is required to observe IBM's ridiculous adherence to not publish the interface, they have all just chosen to do so... Jon Rosen " END-EXEC EXEC SQL EXECUTE REBUTTAL END-EXEC