|
|
Posted by Ed Murphy on 08/03/07 02:12
Shuurai wrote:
>>>> I wasn't talking about passing many parameters, I was talking about passing one parameter that can have many values. <<
>> No, it cannot have many values bey definition. Parameters have to be
>> a scalar value. At one point in ANSI we talked about passing tables
>> in the SQL/PSM and decided against it. Defining comparisons, the
>> parameter declarations and constraints, use of VIEWs, etc. made SQL
>> injection look like a blessing.
>
> The problem with the current method is that it *is* a scalar value.
> Reporting Services creates a comma delimited string containing all of
> the values selected by the user. This can pose problems when there
> are large numbers of values selected. The ability to pass a set would
> be a great benefit, and would not require any changes to the way data
> is stored.
I tend to agree with you - provided that the procedure can define what
type of set is valid, thus avoiding the Squids objection. On the other
hand, if the user /needs/ to select /large/ numbers of values, then
someone should try to refactor the overall system to eliminate that
need; by adding a few appropriate classifying attributes, the user may
be able to select just one or a few such attributes, and the DB can
compute the large list.
Navigation:
[Reply to this message]
|