Re: help with tables

On Thu, 31 Jan 2008 17:38:23 +1300, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:



"Robert" <no@xxxxxx> wrote in message
news:jof2q31shvbu6d9ia1i7gelptabq9slahe@xxxxxxxxxx
On Wed, 30 Jan 2008 10:39:28 -0700, "Frank Swarbrick"
<Frank.Swarbrick@xxxxxxxxxxxxxx>
wrote:

--------------------------------------------------------------------
SQL0060W The "COBOL" precompiler is in progress.
19 SQL0008N The token "occurs" found in a host variable
declaration is not valid.
41 SQL4943W The number of host variables in the INTO clause
is not the same as the number of items in the SELECT
clause. SQLSTATE=01503

The manual says DB2 doesn't allow a simple SELECT to return multiple rows.
You must do the
SELECT in a cursor declaration and read the table with a single FETCH, as
illustrated by
Frederico.

Thanks for the experiment.


While I don't claim the same level of SQL knowledge that you have
demonstrated, Robert, I have managed to use it successfully for a number of
years.

Obviously you CAN return multiple rows from a query if you can process a
result set, however, in embedded SQL I've always used the cursor and FETCHed
it.

Many Cobol programmers think it's not possible to get a result set, except by FETCHing one
row at a time. They regard a database as VSAM on drugs.

I was very interested to see your posts in this thread and hope I've learned
something for the next time I have to deal with Oracle :-)

I'd expect it can be done with any database, because .NET people take sets for granted.

It was partly limitations like this in embedded SQL which caused me to start
looking at LINQ.

At the moment there is some debate as to whether the addition of LINQ
functionality into DotNET languages, and, specifically C#, have caused the
gap to widen between C# and Java. I saw a post from a Java guy who
definitely thinks so, and he explored various options that Sun could do to
try and catch up. None of them were very attractive.

LINQ is integrated into the .NET languages. It doesn't use a clunky precompiler. I wish
SQL were integrated into Cobol. If I were king, I'd drop flat file support from Cobol,
replacing it with SQL for access to indexed and sequential files as well as databases.
I've done that with sequential flat files using Microsoft's ODBC driver. It's surprisingly
fast, even on files containing a million records.

I believe it is approaches such as this that will simply render embedded SQL
obsolete, but time will tell...

LINQ is embedded SQL by another name. I don't think there are any native LINQ databases.
Under the covers LINQ must be converting its queries to dynamic SQL. It's probably holding
locks locally on the client, which will give database purists heartburn.
.

Relevant Pages

  • Re: help with tables
    ... SQL0060W The "COBOL" precompiler is in progress. ... While I don't claim the same level of SQL knowledge that you have ... At the moment there is some debate as to whether the addition of LINQ ... I'd drop flat file support ...
    (comp.lang.cobol)
  • Re: linq versus BindingSource.
    ... Quicker for me is enough when the code behind is translated to real sql. ... I use DbProviderFactory to handle several database types, and manage in code doing this properly with different databases types. ... I need a solution (and I thought, that linq was: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Conversion of data & associated logic from ISAM to RDB
    ... embedded SQL is not necessarily the best solution. ... feed it your ISAM COBOL definition (Source code) and it creates a Relational ... Database in third normal form. ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... OO lends itself to this type of solution, ... >>are database dependent and not available in COBOL. ... a Cobol program can issue any valid SQL ...
    (comp.lang.cobol)
  • Re: Bitwise OR just like SUM or COUNT
    ... the database, **by definition**. ... I don't look at or directly manipulate metadata in ANY of the SQL ... do when I am wearing my programmer hat. ... COBOL & SQL program from an EBCDIC machine ...
    (microsoft.public.sqlserver.programming)