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