home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,769 of 264,096   
   =?UTF-8?Q?Arne_Vajh=C3=B8j?= to All   
   Re: And so? (VMS/XDE)   
   15 Nov 25 18:12:19   
   
   From: arne@vajhoej.dk   
      
   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.   
      
   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.   
      
   >> 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.   
      
   But obviously a dynamically typed language do not have the problem   
   of having to declare query result variable of the correct type.   
      
   >> 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.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca