Re: Can a procedure contain only a SELECT statement?
Date: Thu, 25 Mar 2010 21:05:28 -0000
Message-ID: <KJOdnWoe0LqKTTbWnZ2dnUVZ7s2dnZ2d_at_bt.com>
"Serge Rielau" <srielau_at_ca.ibm.com> wrote in message news:811vmcFklmU1_at_mid.individual.net...
> On 3/25/2010 11:38 AM, Jonathan Lewis wrote:
>> On the other hand, in the SQL Server world you can have a procedure
>> that has no apparent feature for a formal definition of what it's going
>> to
>> output - and therefore no formal mechanism for the front-end to
>> associate
>> what it's expecting with what the database code might deliver.
> Actually I think that is an outdated statement. AFAIK TSQL does at least
> have the concept of table parameters (which is roughly equivalent to an
> associative array of records).
>
There are all sorts of parameters that a procedure can have, and lots of data types that a function can return - but the point I was making was that you can write a procedure that has NO formal parameter declaration that can still "return" data. In the absence of a formal declaration, how does the front end know what to do with the stream of data that gets generated.
> Another key difference of TSQL is that these select statements within a
> batch or procedure flow back to the client immediately.
That, of course, is nearly the problem I was highlighting. The results of
a select statement "flow back" to the client - but how is the client
supposed
to know how to process that stream of data. The procedure may not have
any formal declaration that the client can use to decide how to handle that
data.
-- Regards Jonathan Lewis http://jonathanlewis.wordpress.comReceived on Thu Mar 25 2010 - 16:05:28 CDT