Re: help with tables
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Jan 2008 22:51:59 +1300
"Robert" <no@xxxxxx> wrote in message
news:29n2q3p0caoh922pmsenajrl1niln3j4m3@xxxxxxxxxx
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 disagree. It is integrated into the Language and is an integral part of
the language so it is hardly "embedded", in the sense that SQL is... It is
statically linked at the moment although I saw an interview with Anders
where he said they are currently working on PLINQ which will be parallell
threads of LINQ and these will autmatically be assigned to available
processors. It all looks quite exciting.
I don't think there are any native LINQ databases.
Under the covers LINQ must be converting its queries to dynamic SQL.
Yes, it does that today, but the promise is that the CLR will support PLINQ,
and it is not tied to SQL, as LINQ supports ANY data source, including
in-memory, flat files, even hierarchic databases. The idea is to be able to
slice and dice ALL sources of data, and have these operations automatically
optimized for whatever hardware is available to run them. I suspect it will
take about two years and we'll see it around the same time we see Windows
7... :-)
It's probably holding
locks locally on the client, which will give database purists heartburn.
Maybe... I think we have to accept that initial implementations will not be
perfect... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
.
- References:
- Re: help with tables
- From: Frank Swarbrick
- Re: help with tables
- From: Robert
- Re: help with tables
- From: Pete Dashwood
- Re: help with tables
- From: Robert
- Re: help with tables
- Prev by Date: db2 prep and nested exec sql
- Next by Date: Re: help with tables
- Previous by thread: Re: help with tables
- Next by thread: Re: help with tables
- Index(es):
Relevant Pages
|