From: arne@vajhoej.dk   
      
   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:   
   >>> On Sat, 15 Nov 2025 00:24:04 -0000 (UTC), Waldek Hebisch wrote:   
   >>>> But for routine database queries I want fixed query structure with   
   >>>> data filling slots. Which is provided by embedded SQL and several   
   >>>> alternatives. I do not want arbitrary strings as queries: with   
   >>>> fixed query structure correctness is not hard, with dynamic   
   >>>> strings one needs to consider a lot of weird corner cases.   
   >>>   
   >>> True enough. Fine for canned reports, standard batch processing   
   >>> runs etc. 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.   
      
   So it is:   
      
   Cobol code with EXEC SQL---(preprocessor)--->plain Cobol code---(Cobol   
   compiler)--->object code   
      
   EXEC SQL ... END-EXEC is in itself very simple.   
      
   The tricky part is the mapping between SQL data types and   
   Cobol data types.   
      
   And the handling of errors.   
      
   >>>> Of course, for ad hoc queries you need dynamic query structure,   
   >>>> but ability to specify query structure should be limited to   
   >>>> trusted users.   
   >>>   
   >>> Not if the query is written correctly, which is not hard to do.   
   >>   
   >> C program do not have memory leaks or out of bounds array access if   
   >> written correctly.   
   >   
   > As you may have noticed, it wasn’t C I was recommending for this.   
      
   The point is that all problems arise because something is not   
   written correctly.   
      
   If everything was written correctly there would not be any   
   any software bugs at all.   
      
   But we have many decades of experience for that people do   
   not always write code correctly.   
      
   Best practice is not just to write code correctly, but to   
   do things in a way that make it more difficult not to   
   write code correctly.   
      
   C was just an example of that. An obvious example due to   
   the ongoing debate about memory safe languages. Few are   
   buying the argument "C is fine because the programmers can just   
   write the code correctly".   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)