The article was nice and simple... shows how to make and exec a proc that uses a table parameter.
What I'd like to know (and anyone can certainly answer) is why an app would need to pass an array (table) of parameters to begin with? I'm not a GUI type of guy so I'd really like to know so I can support my Gui Developers better...
If your going to swiftboat me the least you should do is be specific.What exactly are you referring to that doesn't work.?Fish or cut bait.
Heh... you're right... wrong article... it was about "RAAS", not "RAC"...
You'r still nothing more than a spammer... I can't understand why you don't get your product evaluated on this site... what are you afraid of
This is long overdue. I've had this functionality in Oracle for the past ten years (since Oracle 8.0)! When Microsoft introduced the table variable, they never finished the job.
I also noticed that the persistent table definition via the CREATE TYPE statement is the same as Oracle's.
I recently needed this functionality as I had a small 2-dimensional array (table variable, NOT a #temp table) that needed to be processed by other logic which would then return a table result. This 2-dimensional array was used in several procedures. In the interest of good OO programming, a UDF taking in a table-valued parameter and returning a table was the obvious choice. Sadly, I couldn't do it in SQL Server 2005. To use persistent (#) temp tables and/or transform it into XML and then shred it again inside the function was out of the question due to coding and performance overhead.
So I coded the logic in-line within the procedures (performance being the governing factor) with suitable coding comments to refactor the code when SQL Server 2008 is deployed (Q3/Q4 2008).
What was in the array? Might help me understand why people would need to pass such a structure to a proc or function... thanks.
Why? Why do you need to pass a table as a parameter??? Someone please give me an example of an array that would be passed from a GUI to a table in a proc!
Disclaimer - this post has *nothing* to do with RAC
It really is quite simple in the arena of application development.The meaning of a procedure may be applicable to more than a single table. Because of the underlying nature of sql a procedure is usually associated with a particular table. If two tables are candidates for the same outcome (meaning) this usually results in two procedures that do the same thing for 2 different tables. Now you can only pass a table as a parameter to a procedure if the table is a 'variable'. But tables are *not* variables in sql, they are static structures, ie. values/literals/files. So it is necessary to resort to crude workarounds that simulate the idea of a table as a variable, ie. dynamic sql, xml or the Katami idea of a table 'parameter' which is more silliness. The following articles will, I hope, bring the big picture home (assuming they are actually read :http://beyondsql.blogspot.com/2007/09/dataphor-all-tables-are-typed-variables.htmlhttp://beyondsql.blogspot.com/2007/06/dataphor-13-passing-table-as-parameter.htmlhttp://beyondsql.blogspot.com/2007/08/dataphor-creating-super-function.html
Just because someone is an expert sql programmer does not mean they understand (nor the implications) of the computer science(types, variables, and values) of that which they are doing. And justbecause the 'compute science' of sql is not discussed in Bol certainlydoes not mean it doesn't exist. That is the genealogy of sql - a language described as a mile wide and its foundation left an inch deep -
S - structured P - programmingA - absentM - methods