From: arne@vajhoej.dk

On 11/18/2025 2:25 AM, Lawrence D’Oliveiro wrote:
> 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.

The language compiler does not see any embedded SQL - the embedded SQL
pre-processor outputs plain Cobol (or C or whatever).

>        So your code ends up being non-portable

If the SQL used is database specific, then it only works with that
database.

If the non-embedded Cobol code is VMS (or other platform) specific,
then it only works there.

An embedded SQL application may very well be non-portable, but
not due to the use of embedded SQL.

>> 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 SQL language is same SQL language as the database is offering
via other API's.

The mapping to host language variables is the tricky part.

Then you just need to wrap it.

Cobol: EXEC SQL ... END-EXEC
C, Pascal etc.: EXEC SQL ...;
Fortran: EXEC SQL ...
Java: #sql ...;

>>>> 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.

Things progress. Cobol is from 1960. Some progress has been
made since then.

:-)

>                                                                 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.

That works fine in old languages as well.

>>>> 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?

The two biggest languages for embedded SQL must be Cobol and C.

Neither has exceptions.

Newer languages rarely use embedded SQL.

Embedded SQL got defined for Java - I assume IBM and Oracle pushed hard
for it - but nobody is using it.

Arne

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)