From: ldo@nz.invalid   
      
   On Sat, 15 Nov 2025 18:12:19 -0500, Arne Vajhøj wrote:   
      
   > On 11/15/2025 5:16 PM, Lawrence D’Oliveiro wrote:   
   >> On Sat, 15 Nov 2025 09:22:33 -0500, Arne Vajhøj wrote:   
   >>> On 11/15/2025 1:00 AM, Lawrence D’Oliveiro wrote:   
   >>>> On Fri, 14 Nov 2025 22:18:22 -0500, Arne Vajhøj wrote:   
   >>>>> On 11/14/2025 9:41 PM, Lawrence D’Oliveiro wrote:   
   >>>>>>   
   >>>>>> Except COBOL never had any official standard, did it, for these   
   >>>>>> “EXEC SQL” templates.   
   >>>>>   
   >>>>> ISO 9075 part 2   
   >>>>   
   >>>> Something about “data type correspondences”? Not, as I was expecting,   
   >>>> “language constructs for COBOL”? (i.e. not sure what the relevance   
   >>>> is.)   
   >>>   
   >>> Embedded SQL is not a language construct, but a preprocessor   
   >>> construct.   
   >>   
   >> But COBOL doesn’t have a standard preprocessor. Or a standard   
   >> definition for “Embedded SQL”, whether in this ISO spec or any other.   
   >   
   > The embedded SQL pre-processor typical comes from the database vendor.   
      
   But there is no specification in the language standard for how it should   
   work. So your code ends up being non-portable -- defeating much of the   
   point of using COBOL.   
      
   > The ISO SQL standard (part 2 cover the native languages, part 10 cover   
   > Java and possible other object oriented languages) and industry   
   > practices makes it work fine.   
      
   There was nothing in there that I could see about the syntax of SQL   
   embedding, though.   
      
   >>> The tricky part is the mapping between SQL data types and Cobol data   
   >>> types.   
   >>   
   >> Much easier in a dynamic language with a modern-style assortment of   
   >> standard types, like Python.   
   >   
   > The basic types has not changed since the time of Cobol.   
      
   That’s the trouble. But Python includes handy things like dynamic lists/   
   tuples, dictionaries and sets, which are very handy for collecting data   
   from SQL databases, and for putting data into SQL databases. And   
   iterators, so you don’t have to retrieve the entire query result set into   
   memory at once, you can pull in just as much as you can deal with at once.   
      
   > But obviously a dynamically typed language do not have the problem of   
   > having to declare query result variable of the correct type.   
      
   Another advantage when dealing with ad-hoc queries!   
      
   >>> And the handling of errors.   
   >>   
   >> I just let the default exception handling report malformed SQL errors,   
   >> and treat them like program bugs. I.e. I have to fix my code to *not*   
   >> generate malformed SQL.   
   >>   
   >> The only time so far I’ve needed to explicitly catch an SQL error is   
   >> with “IntegrityError”-type exceptions, which can occur if you try to   
   >> insert a record with a duplicate value for a unique key. I only do so   
   >> where this reflects a user error.   
   >   
   > Most languages used for embedded SQL does not use exceptions, so that is   
   > not an option.   
      
   Which ones? It’s not just Python that has them, C++ and Java do, too. Why   
   would you use a language that didn’t have exceptions to work with SQL?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)