Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: c++ and SQL Message-ID: Date: 6 Jun 91 19:12:53 GMT References: <25006@oolong.la.locus.com> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 88 In-reply-to: jfr@locus.com's message of 4 Jun 91 18:27:56 GMT >>>>> On 4 Jun 91 18:27:56 GMT, jfr@locus.com (Jon Rosen) said: Jon> In article Jon> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> Having gone through the process of trying to connect up C++ with an SQL David> preprocessor, I would recommend against attempting it unless you have David> an SQL preprocessor designed to work with C++. Instead, I have found David> that the much more reliable and portable method is to modularize your David> SQL calls into straight C functions so that you may use the standard David> SQL/C preprocessor on them and later link these with the rest of your David> C++ code. The other approach (SQL embedded in C++) will always be a David> hack to interface with the way one SQL preprocessor or C++ compiler David> works. David> For this reason, I believe that the SQL standard should not specify a David> preprocessing standard on top of some other language, but rather a David> method of using SQL that does *not* require a change to the base David> language that it will be used with. If that were the standard, then David> any RDBMS with an SQL interface that works under (for instance) VAX/VMS David> would be able to interface with *all* the languages used on VMS. You David> would not need a special preprocessor for each language. Jon> There are only three ways to introduce SQL capability into a language. Jon> First, you can add it directly to the syntax of the language. Second, Jon> you can provide a call-level interface. Third, you can provide a Jon> preprocessor which converts something that looks like native syntax into Jon> actual native syntax and calls to a supplied run-time call-level Jon> interface. The argument you give is for a direct call-level interface. Jon> The argument against this idea (given by IBM when SQL/DS was released) is Jon> that a call-level interface directly available to the user limits the Jon> ability of the vendor to enhance the interface in the future or optimize Jon> the use of the interface in the future without requiring possible changes Jon> to the source code. Not if you consider the call-level interface to be standard. When the call-level interface is standard, then changes to that standard have exactly the same results as changing the definition of SQL. The difference is that the language (and its support environments) in which SQL is embedded need know *nothing* about SQL. Note, there is nothing that says the SQL Module itself can't be implemented via the hidden interface. Users, though, only require a bare minimum of that interface. Jon> Using an abstract syntax enhancement which hides much of the internal Jon> detail needed to support SQL (such things as placing data and nulls into Jon> host variables and the like) makes it much simpler to enhance the Jon> interface (i.e., the preprocessor and the call-level run-time routine) Jon> without needing to have the user make changes in the program. This was Jon> deemed a critical issue. While C programmers may not find it a good Jon> argument (although I don't see why, since we all use our own preprocessor Jon> to support our programming already), it was essential for COBOL Jon> programmers which is the prrimary market IBM is aimed at. If you're comparing with C++, that's still a sore issue where debugging and other environmental support is concerned. Even in the face of these precompilers, how does COBOL code handle things like NULLS and placing data into host variables? I contend that COBOL programmers must still set aside data variables for these things and give them to SQL. A call-level interface would not affect that. Jon> My only complaint is that there was (and is) no need to make the Jon> underlying call-level interface a magic hidden thing... IBM could have Jon> published it as well as the preprocessor interface and stated that they Jon> expressly reserved the right to make major changes in the call-level Jon> interface at any time... Using the preprocessor would protect you but Jon> using the call-level would allow you to interface easily with languages Jon> that didn't have a preprocessor capablity. This they chose not to do so Jon> language support is limited to use in languages that have an SQL Jon> preprocessor... By the way, no other vendor is required to observe IBM's Jon> ridiculous adherence to not publish the interface, they have all just Jon> chosen to do so... Which is distressing because it used to be that this was not a terrible burden when using SQL embedded in C (or any supported language). The problem, though, multiplies significantly when trying to interface an SQL preprocessor with another language preprocessor (in this case, C++, but it could just as easily have been RATFOR, M4, or a host of others). By using a preprocessor to a language, the environment of the original language is broken. The more preprocessors you add, the more broken the environment. Where SQL is concerned, there was no need for it to be environment hostile. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"