Something I'm wondering, in the general case, are the table values being passed
on these parameters large or small? For example, is it a list of line items for
an invoice (small) or could it say be millions of records in one call? I say
this regardless of whether these values are being passed in or out or both,
though you can answer that too.
If the tables are large then we probably want the implementation such that the
client-side bind variable on that parameter would be like a cursor handle so you
can pull or push rows one at a time; if the tables are small than an
implementation that behind the scenes serializes the table into a scalar value
for transit may do the job.
As to the actual answer to your question, what support exists now, I don't know;
I'm just saying how it could be made to work.
Note that an ordinary SELECT or INSERT statement could be generalized as a
procedure with a table-valued OUT or IN parameter respectively, and so an
appropriate DBI design could handle things as if a SELECT/INSERT were just
special cases of the procedure. DBI's ? bind params and stored procedure params
would be direct analogies to each other, or say that the former is an example of
the latter.
-- Darren Duncan
On 2013.12.29 2:20 PM, Jürgen Wenzel wrote:
Hello,
I'm adapting a Windows perl program to work with a new MS SQL Server database
and it involves making calls to stored procedures that takes Table-Valued
Parameters. Is this possible with DBD::ODBC or any other DBI? Or at all with
(strawberry) perl?
Would really appreciate some help -- answers and perhaps even a short example --
since trying to figure this out is really starting to wear on me.
Thanks in advance!
JW
