From: ldo@nz.invalid   
      
   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 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.   
      
   > 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.   
      
   > The point is that all problems arise because something is not written   
   > correctly.   
      
   The point is that some languages are better suited to this sort of problem   
   than others. Trying to wrestle your way through with an antiquated   
   language is not a recipe for producing quality code.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)