Discussion:
Teaching, was: Re: Any stronger versions of the LMF planned ?
(too old to reply)
Simon Clubley
2021-08-12 12:15:22 UTC
Permalink
Then, a decade or two later, came along these things called ?relational databases?, which were enthusiastically adopted by businesses--the very market that COBOL was supposedly optimized for.
But it turns out the best way to interface to a relational DBMS is to generate SQL query strings. And for that, you need decent string handling, with facilities for format substitution, argument quoting and the like. None of which were envisaged in the original design of COBOL.
Are you kidding me ????? :-( :-( Is that what is taught in university ? :-(

If _that_ is what is being taught today then that is a perfect example of
how teaching and teachers are completely out of touch with the real world.

You need to learn the SQL syntax and how to apply it to applications but
you should be using a parameter based API to actually build the SQL query.

The _only_ time building a SQL query string manually is acceptable is
if what you are using is so old that it does not support parameter based
SQL statements.

In university, you should be taught the parameter based approach first
and only then told that on some old systems you may need to construct
the SQL query manually and there should then be a detailed discussion
about the security implications of doing that.

If this isn't being done then that is a perfect example of how university
teaching is utterly out of touch with the real world.
So today, even a language like Python, Perl or (spit) PHP would be a better fit for ?business needs? than COBOL ...
How well do these languages handle decimal data ?

There's a reason why that is the preferred format in business applications.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-08-12 14:28:45 UTC
Permalink
Post by Simon Clubley
Then, a decade or two later, came along these things called
?relational databases?, which were enthusiastically adopted by
businesses--the very market that COBOL was supposedly optimized
for.
But it turns out the best way to interface to a relational DBMS is
to generate SQL query strings. And for that, you need decent string
handling, with facilities for format substitution, argument quoting
and the like. None of which were envisaged in the original design
of COBOL.
Are you kidding me ????? :-( :-( Is that what is taught in university ? :-(
If _that_ is what is being taught today then that is a perfect
example of how teaching and teachers are completely out of touch with
the real world.
You need to learn the SQL syntax and how to apply it to applications
but you should be using a parameter based API to actually build the
SQL query.
They should learn SQL and they should of course use parameters.

But in majority of cases they will actually use an ORM not SQL.
Post by Simon Clubley
The _only_ time building a SQL query string manually is acceptable
is if what you are using is so old that it does not support parameter
based SQL statements.
There are a few cases where parameters cannot be used and one need to
fallback to string concatenation even if the database API generally
support parameters.
Post by Simon Clubley
So today, even a language like Python, Perl or (spit) PHP would be
a better fit for ?business needs? than COBOL ...
How well do these languages handle decimal data ?
Python fine.

PHP will require an external library but such exist.

I don't know about Perl.

Java, C#, VB.NET, VMS Basic, Delphi etc. also got decimal types.
Post by Simon Clubley
There's a reason why that is the preferred format in business
applications.
Yes.

Arne
Craig A. Berry
2021-08-12 17:43:40 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
How well do these languages handle decimal data ?
Python fine.
PHP will require an external library but such exist.
I don't know about Perl.
There are libraries that do it, but they aren't fast. There is a recent
proposal to add it natively to the core language:

<https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261129.html>

Whether, how, or when that might get implemented is up for grabs.
Lawrence D’Oliveiro
2021-08-12 23:40:33 UTC
Permalink
Post by Simon Clubley
You need to learn the SQL syntax and how to apply it to applications but
you should be using a parameter based API to actually build the SQL query.
There seems to be a lot of fear and loathing around the simple concept of properly escaping parameter values in SQL and other embedded languages, isn’t there? This stuff isn’t so hard--they’re all just regular grammars, after all.

All the decent DBMS APIs offer a “format_sql_value()” function or equivalent anyway. Though strangely, none of them, that I have seen, have an “escape_sql_wildcard()” that you can use to turn user-entered literal data into a LIKE clause. So I find myself having to roll my own.

But this is getting away from the point, that COBOL’s supposed “business” orientation actually built-in a massive blind spot to what was actually emerging as business needs.
Arne Vajhøj
2021-08-13 00:47:26 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Simon Clubley
You need to learn the SQL syntax and how to apply it to
applications but you should be using a parameter based API to
actually build the SQL query.
There seems to be a lot of fear and loathing around the simple
concept of properly escaping parameter values in SQL and other
embedded languages, isn’t there?
Yes.

Experience has shown that escaping parameter values frequently goes
wrong.

Prepared statement / parameters is the right solution.
Post by Lawrence D’Oliveiro
This stuff isn’t so hard--they’re
all just regular grammars, after all.
It can get very messy with Unicode and different character sets
in play.
Post by Lawrence D’Oliveiro
All the decent DBMS APIs offer a “format_sql_value()” function or
equivalent anyway.
No.

Decent database API's provide support for prepared statement /
parameters.

Some may provide a function like the one you describe, but usage
of it is a serious code smell.
Post by Lawrence D’Oliveiro
But this is getting away from the point, that COBOL’s supposed
“business” orientation actually built-in a massive blind spot to what
was actually emerging as business needs.
COBOL embedded SQL to relational databases works fine.

Arne
Lawrence D’Oliveiro
2021-08-13 02:00:20 UTC
Permalink
Post by Arne Vajhøj
Experience has shown that escaping parameter values frequently goes
wrong.
Your experience? Because you don’t understand what a regular grammar is?
Post by Arne Vajhøj
It can get very messy with Unicode and different character sets
in play.
That may be have been true in the days before UTF-8. In this century, that particular problem is finally solved.
Post by Arne Vajhøj
Decent database API's provide support for prepared statement /
parameters.
I don’t see any that deal with LIKE clauses, though, for example. How do you cope with that? Or in your world, do you just run away screaming?
Jan-Erik Söderholm
2021-08-13 07:53:46 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Arne Vajhøj
Experience has shown that escaping parameter values frequently goes
wrong.
Your experience? Because you don’t understand what a regular grammar is?
Post by Arne Vajhøj
It can get very messy with Unicode and different character sets
in play.
That may be have been true in the days before UTF-8. In this century, that particular problem is finally solved.
Post by Arne Vajhøj
Decent database API's provide support for prepared statement /
parameters.
I don’t see any that deal with LIKE clauses, though, for example.
I do not see why a LIKE could not take a paramater. But on the other
hand, in real business applications, I do not think that the use of LIKE
SQL clause in particular is that common. It has some performance
implications.

Anyway, the source of many SQL injection issues over the times has
been the use of simple string handling in tools like PHP. When you
see PHP SQL code, it is usually using string handling and not prepare
statements and paramater markers (where SQL injection is not possible).
Post by Lawrence D’Oliveiro
How do you cope with that? Or in your world, do you just run away screaming?
Childish comment.
Lawrence D’Oliveiro
2021-08-18 08:22:16 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Lawrence D’Oliveiro
I don’t see any that deal with LIKE clauses, though, for example.
I do not see why a LIKE could not take a paramater.
Do you understand what kind of parameters it needs to take?
Post by Jan-Erik Söderholm
But on the other hand, in real business applications, I do not think that
the use of LIKE SQL clause in particular is that common. It has some
performance implications.
That seems to be the COBOL answer, isn’t it? Redefine “business” needs to exclude the stuff it can’t cope with. Good luck with that.
Post by Jan-Erik Söderholm
Post by Lawrence D’Oliveiro
How do you cope with that? Or in your world, do you just run away screaming?
Childish comment.
Well, that’s two ways you’ve answered that question ...
Arne Vajhøj
2021-08-13 12:28:03 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Arne Vajhøj
Decent database API's provide support for prepared statement /
parameters.
I don’t see any that deal with LIKE clauses, though, for example. How
do you cope with that? Or in your world, do you just run away
screaming?
I have never seen an implementation of prepared statement that
did not support LIKE.

... f LIKE ?

(or whatever the placeholder is)

Arne
Jan-Erik Söderholm
2021-08-13 12:47:09 UTC
Permalink
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Post by Arne Vajhøj
Decent database API's provide support for prepared statement /
parameters.
I don’t see any that deal with LIKE clauses, though, for example. How
do you cope with that? Or in your world, do you just run away
screaming?
I have never seen an implementation of prepared statement that
did not support LIKE.
... f LIKE ?
(or whatever the placeholder is)
Arne
The question is if you should expect the user to add the correct
wildcards, or if you need/want to simply add an % before and after
the search string supplied by the user.

And of course it is no issue to prepare that statement anyway...

And, a bank do not excpect to lookup a bank account whos number
is "like" something.
Arne Vajhøj
2021-08-13 14:44:54 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Post by Arne Vajhøj
Decent database API's provide support for prepared statement /
parameters.
I don’t see any that deal with LIKE clauses, though, for example. How
do you cope with that? Or in your world, do you just run away
screaming?
I have never seen an implementation of prepared statement that
did not support LIKE.
... f LIKE ?
(or whatever the placeholder is)
The question is if you should expect the user to add the correct
wildcards, or if you need/want to simply add an % before and after
the search string supplied by the user.
In most cases it should be added by the application code.
Post by Jan-Erik Söderholm
And of course it is no issue to prepare that statement anyway...
True.

Java & JDBC:

PreparedStatement sel = con.prepare("... WHERE f LIKE ?");
sel.setString(1, fval + "%");

Arne
Lawrence D’Oliveiro
2021-08-18 08:19:51 UTC
Permalink
Post by Arne Vajhøj
PreparedStatement sel = con.prepare("... WHERE f LIKE ?");
sel.setString(1, fval + "%");
Do I need to point out what’s wrong with that?
Jan-Erik Söderholm
2021-08-18 08:44:30 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Arne Vajhøj
PreparedStatement sel = con.prepare("... WHERE f LIKE ?");
sel.setString(1, fval + "%");
Do I need to point out what’s wrong with that?
You do not *have* to do anything, but why not?

Simon Clubley
2021-08-13 12:06:18 UTC
Permalink
Post by Simon Clubley
You need to learn the SQL syntax and how to apply it to applications but
you should be using a parameter based API to actually build the SQL query.
There seems to be a lot of fear and loathing around the simple concept of properly escaping parameter values in SQL and other embedded languages, isn?t there? This stuff isn?t so hard--they?re all just regular grammars, after all.
Yes there is. Programmers don't like it when their code ends up being
analyzed inside of a CVE.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
David Jones
2021-08-13 03:20:51 UTC
Permalink
Post by Simon Clubley
The _only_ time building a SQL query string manually is acceptable is
if what you are using is so old that it does not support parameter based
SQL statements.
The textbook I used in college was printed in1982 and even its dialect of SQL
had parameterized statements.
Lawrence D’Oliveiro
2021-08-13 03:54:11 UTC
Permalink
Post by David Jones
The textbook I used in college was printed in1982 and even its dialect of SQL
had parameterized statements.
Did your course cover QBE? Only that was considered a separate query language in those days, not something you could build on top of SQL.
David Jones
2021-08-13 16:35:06 UTC
Permalink
Post by Lawrence D’Oliveiro
Did your course cover QBE? Only that was considered a separate query language in those days, not something you could build on top of SQL.
They skipped that chapter. The thrust of the course was introducing the concepts, no teaching a particular language.
Arne Vajhøj
2021-08-13 12:25:18 UTC
Permalink
Post by David Jones
Post by Simon Clubley
The _only_ time building a SQL query string manually is acceptable is
if what you are using is so old that it does not support parameter based
SQL statements.
The textbook I used in college was printed in1982 and even its dialect of SQL
had parameterized statements.
There are a few old API's without.

MySQL C API before 5.0 and PHP mysql extension based on same.

Sybase/MS DBLIB API.

Arne
Loading...