sql server (alternate): Hi Friends,
Is it possible to pass a table as a parameter to a funtion.

whos function declaration would look some thing like this....
ALTER FUNCTION TempFunction (@TempTable TABLE, @nPId INT)


my problem is: i have to access a temporary table created in an SP in
a function


ALTER PROCEDURE MySP
BEGIN
....
DECLARE @TmpTable TABLE(...)
....
TempFunction(@TmpTable)
....
END


Thanks
ArunDhaJ

ArunDhaJ (arundhaj@gmail.com) writes:
[quoted text, click to view]

It should be in SQL 2008, which currently is in beta. The functionality
is available in the current CTP, but I have not played with it, so I
can't say for sure that it works with functions.

[quoted text, click to view]

You probably need to rewrite the function as a procedure. See here for
some tips of passing data between stored procedures in current SQL versions.
http://www.sommarskog.se/share_data.html

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at

Here you go and it's not wishful thinking -:)

http://beyondsql.blogspot.com/2007/06/dataphor-13-passing-table-as-parameter.html

www.beyondsql.blogspot.com

As already suggested a procedure will work. We have a procedure to
drop all default constraints from our tables. I pass in a list of
tables to this procedure (the list of tables are loaded in to a table
variable by calling a function). If you need further help then re-post
and I can hopefully give you an example!

Paul

[quoted text, click to view]

Hi All,
Thanks for your response.. :)

Ya.. the procedure will do fine....
But my question is that is there any performance difference between
using functions and procedure....

Thanks
ArunDhaJ

ArunDhaJ (arundhaj@gmail.com) writes:
[quoted text, click to view]

That all depends on how you implement and use them. You can't say that any
is faster than the other as such.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at

[quoted text, click to view]

Please read a book, any book, on data modeling, and RDBMS. A table is
an entity or a relationship. That would mean you have a magical,
super function that works on Squids, Automobiles, Britney Spears,
Geographical locations or anything in the whole of creation.

Or you have a bad design which you are not showing us. That is what Ia
m beting.

[quoted text, click to view]

No, you do not. You just don't know how to write declarative, non-
procedural code so you are mimicking a scratch tape with a table that
appears out nowhere in your data model as if you were still using a
magnetic tape file system instead of an RDBMS.

[quoted text, click to view]

No; it would much more likely mean that he wants to pass a set of
values to his function. There are various reasons to want something
like this, I'll give you a prime example: When passing mutli-value
parameters in Reporting Services, the most common method is to use IN
- so you might have a parameter @someParam and then in your underlying
queries you'll have WHERE some_column in ( @someParam )

This can lead to performance issues when the number of values in the
parameter are very large, and in some cases can even fail to run
because essentially SRS creates a long comma delimited string; but
there is a limit to the size that string can be. There are
workarounds, of course, but having the ability to simply pass a set
would make things enormously easier, faster, and cleaner - which is
probably why they're including it in SQL 2008.

[quoted text, click to view]

I am betting your lack of real-world development experience has
rendered you incapable of understanding why someone would need this.

[quoted text, click to view]

I can think of several scenarios in which doing exactly what he is
asking would be necessary - reporting being the most obvious.

[quoted text, click to view]

Not very likely at all. Read the last 5+ years of postings here and
you will see that when they want to pass a list to an IN() predicate,
they explicitly ask about that. When they want to pass a table they
explicitly ask about that, as this guy did.

[quoted text, click to view]

Right now you can declare a huge number of parameters in a stored
procedure -- more than enough for any practical situation. But
programmers who grew up with BASIC and other interpreted languages
seem to panic at the the thought of a long parameter list.

[quoted text, click to view]
asking would be necessary - reporting being the most obvious. <<

The most obvious is a system utility program which treats all tables
as tables rather than as part of a logical model. Now you are at the
meta data level, which has no place in an application or RDBMS
schema.

[quoted text, click to view]

And do you suppose his interest is in the table itself, or the set of
data that the table contains?

[quoted text, click to view]

Clearly you did not understand the example I gave you. I wasn't
talking about passing many parameters, I was talking about passing one
parameter that can have many values. A drop-down list where the user
can select more than one value. In other words, a set. This is an
EXTREMELY common scenario in the real world.

Classroom coders who have little to no development experience in the
real world tend to panic at the thought of examples that are outside
of their limited experience :b

[quoted text, click to view]

Procedures with long lists of parameters simply cannot be fully tested
in reasonable time. Just think how many permutations are there for
1000 nullable parameters. Any responsible professional will avoid
using untested code in real life...

[quoted text, click to view]

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.

[quoted text, click to view]

Gee, I looked all over my SQL Standards and books, but could not find
a drop-down list mentioned. Are you sure that is not part of the
front end and not something which a good programmer would in the
database :)?

[quoted text, click to view]

Yes, in the applications side of the real world, not the database.
Hey, there is nothing wrong with being an application programmer. But
it is a different tier.

[quoted text, click to view]

LOL! I have been gathering "limited experience" for over 35 years
now! And I have had some influence on RDBMS over the last few
decades. Instead of being a "code monkey" any more, I get called in
to train progammers, design DBs and repair disasters. Part of me
misses the programming discipline of a military weapons or medical
records system. If it screws up even a little or if it goes down, the
wrong people die.

You mention the pull-down list. When I was in Salt Lake City, I did a
little volunteer work for an African relief group. They drop medical
supplies into war zones. You cannot drop large cargo crates because
they will be captured or shot down before they can be gathered up.
Instead, you parachute small crates so that x-% will be delivered
(good math problem! My first Masters was in Math).

But that means the crates have to be packed with smaller units of
supplies. The suppliers were willing to give donations in larger
packages (i.e. 10,000 boxes of 100 units of an antibiotic in one cargo
crate). Volunteers would then break that into smaller units by hand;
a hell of a lot of manual labor.

The suppliers then agreed to provide packages of 10 units, so the
volunteers could put relief packages together without opening,
counting and re-packing 10 units in homemade containers from 100 unit
packages.

A volunteer programmer did a pull-down list where the package options
were in a comma separated list column in the DB. It made his display
easier. But it messed up the pick list when smaller units were
available. People thought they were asking for 100 units, but it
became 10 units in the backend.

His little violation of 1NF and blending of tiers meant that field
medical personnel had to decide which children would and would not get
antibiotics.

We have to find the shortages (or overages -- just as bad) and get
corrections for them into the field. Then we needed a smarter
volunteer programmer who could do it right.

That is a day in the life of "Classroom coder"; so what did you do
today?

An observation from decades of experience: the **average** programmer
is getting worse. Kids with no University degree, no accounting
courses, no statistics course, no comp sci courses, no nothing are
taking a cram course for an MS certification to get jobs. The jobs
being outsourced are going to non-English speakers who are just as bad
or worse!

In the old days, the hardware was expensive and you had to apprentice
for years under someone before you got to do production code. Now,
machines are cheap and "code monkey" programmers are not regarded as a
skilled employee. Enough monkeys on a keyboard can produce something
and if it is cheap enough and failure is not lethal, what the heck!

You might want to Google up http://www.apa.org/journals/psp/psp7761121.html

It is a 1999 article in the Journal of Personality and Social
Psychology by Justin Kruger and David Dunning entitled "Unskilled and
Unaware of It: How Difficulties in Recognizing One's Own Incompetence
Lead to Inflated Self-Assessments"

[quoted text, click to view]

I prefer the "Rule of seven plus or minus two" (http://www.musanim.com/
miller1956/) for a parameter list -- classic Software Engineering.

But you do not test all permutations in a repeated group. I can see
that "p001" to "p999" are all integers, that they are loaded into a
table named "Parts" and are therefore subject to the constraints on
that table. That is simple induction and set-oriented programming.

[quoted text, click to view]

Agreed. I wish there were more them than "Agile Programmers" :) That
is why I like Dijkstra, Mana, Gries, et al -- I want my code to be
provably correct.

I did QA for weapons systems in my youth. I was probably shooting at
you :)

[quoted text, click to view]

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.

That aside, your statement that procedures can have many parameters is
meaningless - it doesn't even remotely address the question. Either
you didn't understand the question, or you simply spit out one of your
standard cookie-cutter replies that you felt could best be wedged into
the discussion.

[quoted text, click to view]

The drop-down list *is* in the front end; which is Reporting
Services. Reporting Services uses SQL queries or stored procedures to
pull data. Therefore - stay with me, Joe - those queries/procedures
have to be written to accomidate multiple selections for a drop down
menu.

I strongly suspect that most businesses aren't going to stop using
this functionality just because you say it shouldn't work or that it
isn't standard; nor are they going to wait for Microsoft to create
some additional tier in between Reporting Services and the database;
especially when such a tier is not needed.

[quoted text, click to view]

In this case the only efficient means of getting the data with the
parameters needed is via SQL script or stored procedure; in either
case requiring that SQL be written to handle multiple selections.

[quoted text, click to view]

How many years has it been since you've done any real work in the
field?

[snip]

[quoted text, click to view]

What he did has nothing to do with anything I'm currently talking
about. I haven't said anything about storing comma delimited lists in
columns in the database, or anything like that. Nothing like that is
even necessary. In fact, nothing I am talking about requires any
change whatsoever in how the data is stored.

As you so often do, you are now pulling out and emotionally charged
disaster scenario that is at best superficially related to the topic
at hand. I tell you that it'd be nice to be able to pass a set as a
parameter, and you go into a story about how a bunch of kids didn't
get medicine because some bad programmer made an obvious error that
spread across tiers. Sad story, no doubt, but it has nothing to do
with what we're talking about.

[quoted text, click to view]

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

Comparing the CSV approach with the parameter approach below, which one do
you consider more maintainable and supportable?

Also consider the application will need one line per parameter used on the
stored procedure.

This which takes milliseconds to edit in Management Studio....

create proc getdata_dynamic
@csv varchar(max)

as
set @csv = replace( @csv, '''', '''''' )

exec( ' DECLARE @c int
select @c = count(*)
from somedata
where avalue in ( ' + @csv + ' )'
)
go

Or this which takes over two minutes to edit in Management Studio (on a 4GB
dual proc AMD machine)....

create proc [dbo].[getdata_parms] @p1 int, @p2 int, @p3 int, @p4 int, @p5
int, @p6 int, @p7 int, @p8 int, @p9 int, @p10 int, @p11 int, @p12 int, @p13
int, @p14 int, @p15 int, @p16 int, @p17 int, @p18 int, @p19 int, @p20 int,
@p21 int, @p22 int, @p23 int, @p24 int, @p25 int, @p26 int, @p27 int, @p28
int, @p29 int, @p30 int, @p31 int, @p32 int, @p33 int, @p34 int, @p35 int,
@p36 int, @p37 int, @p38 int, @p39 int, @p40 int, @p41 int, @p42 int, @p43
int, @p44 int, @p45 int, @p46 int, @p47 int, @p48 int, @p49 int, @p50 int,
@p51 int, @p52 int, @p53 int, @p54 int, @p55 int, @p56 int, @p57 int, @p58
int, @p59 int, @p60 int, @p61 int, @p62 int, @p63 int, @p64 int, @p65 int,
@p66 int, @p67 int, @p68 int, @p69 int, @p70 int, @p71 int, @p72 int, @p73
int, @p74 int, @p75 int, @p76 int, @p77 int, @p78 int, @p79 int, @p80 int,
@p81 int, @p82 int, @p83 int, @p84 int, @p85 int, @p86 int, @p87 int, @p88
int, @p89 int, @p90 int, @p91 int, @p92 int, @p93 int, @p94 int, @p95 int,
@p96 int, @p97 int, @p98 int, @p99 int, @p100 int, @p101 int, @p102 int,
@p103 int, @p104 int, @p105 int, @p106 int, @p107 int, @p108 int, @p109 int,
@p110 int, @p111 int, @p112 int, @p113 int, @p114 int, @p115 int, @p116 int,
@p117 int, @p118 int, @p119 int, @p120 int, @p121 int, @p122 int, @p123 int,
@p124 int, @p125 int, @p126 int, @p127 int, @p128 int, @p129 int, @p130 int,
@p131 int, @p132 int, @p133 int, @p134 int, @p135 int, @p136 int, @p137 int,
@p138 int, @p139 int, @p140 int, @p141 int, @p142 int, @p143 int, @p144 int,
@p145 int, @p146 int, @p147 int, @p148 int, @p149 int, @p150 int, @p151 int,
@p152 int, @p153 int, @p154 int, @p155 int, @p156 int, @p157 int, @p158 int,
@p159 int, @p160 int, @p161 int, @p162 int, @p163 int, @p164 int, @p165 int,
@p166 int, @p167 int, @p168 int, @p169 int, @p170 int, @p171 int, @p172 int,
@p173 int, @p174 int, @p175 int, @p176 int, @p177 int, @p178 int, @p179 int,
@p180 int, @p181 int, @p182 int, @p183 int, @p184 int, @p185 int, @p186 int,
@p187 int, @p188 int, @p189 int, @p190 int, @p191 int, @p192 int, @p193 int,
@p194 int, @p195 int, @p196 int, @p197 int, @p198 int, @p199 int, @p200 int,
@p201 int, @p202 int, @p203 int, @p204 int, @p205 int, @p206 int, @p207 int,
@p208 int, @p209 int, @p210 int, @p211 int, @p212 int, @p213 int, @p214 int,
@p215 int, @p216 int, @p217 int, @p218 int, @p219 int, @p220 int, @p221 int,
@p222 int, @p223 int, @p224 int, @p225 int, @p226 int, @p227 int, @p228 int,
@p229 int, @p230 int, @p231 int, @p232 int, @p233 int, @p234 int, @p235 int,
@p236 int, @p237 int, @p238 int, @p239 int, @p240 int, @p241 int, @p242 int,
@p243 int, @p244 int, @p245 int, @p246 int, @p247 int, @p248 int, @p249 int,
@p250 int, @p251 int, @p252 int, @p253 int, @p254 int, @p255 int, @p256 int,
@p257 int, @p258 int, @p259 int, @p260 int, @p261 int, @p262 int, @p263 int,
@p264 int, @p265 int, @p266 int, @p267 int, @p268 int, @p269 int, @p270 int,
@p271 int, @p272 int, @p273 int, @p274 int, @p275 int, @p276 int, @p277 int,
@p278 int, @p279 int, @p280 int, @p281 int, @p282 int, @p283 int, @p284 int,
@p285 int, @p286 int, @p287 int, @p288 int, @p289 int, @p290 int, @p291 int,
@p292 int, @p293 int, @p294 int, @p295 int, @p296 int, @p297 int, @p298 int,
@p299 int, @p300 int, @p301 int, @p302 int, @p303 int, @p304 int, @p305 int,
@p306 int, @p307 int, @p308 int, @p309 int, @p310 int, @p311 int, @p312 int,
@p313 int, @p314 int, @p315 int, @p316 int, @p317 int, @p318 int, @p319 int,
@p320 int, @p321 int, @p322 int, @p323 int, @p324 int, @p325 int, @p326 int,
@p327 int, @p328 int, @p329 int, @p330 int, @p331 int, @p332 int, @p333 int,
@p334 int, @p335 int, @p336 int, @p337 int, @p338 int, @p339 int, @p340 int,
@p341 int, @p342 int, @p343 int, @p344 int, @p345 int, @p346 int, @p347 int,
@p348 int, @p349 int, @p350 int, @p351 int, @p352 int, @p353 int, @p354 int,
@p355 int, @p356 int, @p357 int, @p358 int, @p359 int, @p360 int, @p361 int,
@p362 int, @p363 int, @p364 int, @p365 int, @p366 int, @p367 int, @p368 int,
@p369 int, @p370 int, @p371 int, @p372 int, @p373 int, @p374 int, @p375 int,
@p376 int, @p377 int, @p378 int, @p379 int, @p380 int, @p381 int, @p382 int,
@p383 int, @p384 int, @p385 int, @p386 int, @p387 int, @p388 int, @p389 int,
@p390 int, @p391 int, @p392 int, @p393 int, @p394 int, @p395 int, @p396 int,
@p397 int, @p398 int, @p399 int, @p400 int, @p401 int, @p402 int, @p403 int,
@p404 int, @p405 int, @p406 int, @p407 int, @p408 int, @p409 int, @p410 int,
@p411 int, @p412 int, @p413 int, @p414 int, @p415 int, @p416 int, @p417 int,
@p418 int, @p419 int, @p420 int, @p421 int, @p422 int, @p423 int, @p424 int,
@p425 int, @p426 int, @p427 int, @p428 int, @p429 int, @p430 int, @p431 int,
@p432 int, @p433 int, @p434 int, @p435 int, @p436 int, @p437 int, @p438 int,
@p439 int, @p440 int, @p441 int, @p442 int, @p443 int, @p444 int, @p445 int,
@p446 int, @p447 int, @p448 int, @p449 int, @p450 int, @p451 int, @p452 int,
@p453 int, @p454 int, @p455 int, @p456 int, @p457 int, @p458 int, @p459 int,
@p460 int, @p461 int, @p462 int, @p463 int, @p464 int, @p465 int, @p466 int,
@p467 int, @p468 int, @p469 int, @p470 int, @p471 int, @p472 int, @p473 int,
@p474 int, @p475 int, @p476 int, @p477 int, @p478 int, @p479 int, @p480 int,
@p481 int, @p482 int, @p483 int, @p484 int, @p485 int, @p486 int, @p487 int,
@p488 int, @p489 int, @p490 int, @p491 int, @p492 int, @p493 int, @p494 int,
@p495 int, @p496 int, @p497 int, @p498 int, @p499 int, @p500 int, @p501 int,
@p502 int, @p503 int, @p504 int, @p505 int, @p506 int, @p507 int, @p508 int,
@p509 int, @p510 int, @p511 int, @p512 int, @p513 int, @p514 int, @p515 int,
@p516 int, @p517 int, @p518 int, @p519 int, @p520 int, @p521 int, @p522 int,
@p523 int, @p524 int, @p525 int, @p526 int, @p527 int, @p528 int, @p529 int,
@p530 int, @p531 int, @p532 int, @p533 int, @p534 int, @p535 int, @p536 int,
@p537 int, @p538 int, @p539 int, @p540 int, @p541 int, @p542 int, @p543 int,
@p544 int, @p545 int, @p546 int, @p547 int, @p548 int, @p549 int, @p550 int,
@p551 int, @p552 int, @p553 int, @p554 int, @p555 int, @p556 int, @p557 int,
@p558 int, @p559 int, @p560 int, @p561 int, @p562 int, @p563 int, @p564 int,

[quoted text, click to view]

the repeated code is easy to maintain with a text edit, but let's talk
about portable code, how people should code, etc.

1) most people will not type in more than 10 to 25 parameters and they
*seldom* need to. When an input list gets long, you need to load a
table and scrub the data before you invoke the procedure.

2) what code do "CSV spliter" people write to hande strings like
'1,,,4', or 'NULL, NULL, 2' or '1, ''2.34'', 7' or whatever? there
is no parsing or error handling and therefore no data integrity.

[quoted text, click to view]

unh? chunking will put related parameters on one line in a logical
contigous ordering.

[quoted text, click to view]

if the code does not have to do validatiion and produce correct data,
who cares about a fast wrong answer? I was one of the first people to
do a CSV scan in a single SQL query. I wrote a kludge. I repent of
my evil.

[quoted text, click to view]

Why sacrifise maintainability, support costs, development costs, simplicity
of design for something nobody wants? Nobody is interested in portability.

[quoted text, click to view]

Not it isn't, have you tried? Cut and paste problems; how long will it take
you to type all those parameters and test each possible parameter
combination to make sure you got it right? Answer - a long time.

[quoted text, click to view]

Are you sure about that? Why are you suggesting people can use 1,000
parameters then - you have made a general design advisary statement.

[quoted text, click to view]

Oh yes, the other scalability and concurrency weakness in the design you
propose. It doesn't scale.

[quoted text, click to view]

Who mentioned CSV splitter; there is no need with dynamic SQL.

If you wanted to you could even, using dynamic SQL, take the CSV parameter
input and populate a table thus....

That gives you the full referential integrity checking for the values
passed.

Nothing complicated about the stuff below; no procedural loops etc...

create proc csv_eg
@csv varchar(500)
as
begin
-- check we have commas correct
set @csv = ltrim(rtrim(@csv))

if left( @csv, 1 ) <> ','
set @csv = ',' + @csv
if right( @csv, 1 ) = ','
set @csv = @csv + 'NULL'

set @csv = replace( @csv, ',,', ',NULL,' )
set @csv = replace( @csv, ',,', ',NULL,' ) -- captures rest of ,, not
caught in first one

-- done.

set @csv = replace( @csv, '''', '''''' ) -- get rid of injection
attempt

declare @sql varchar(max)

set @sql = replace( @csv, ',', char(13) + char(10) + 'insert #csv_split
( csv_value ) values( ' )
set @sql = replace( @sql, char(13), ' )' + char(13) )
set @sql = right( @sql, len( @sql ) - 4 ) + ' )'

create table #csv_split (
csv_value int null check( csv_value between 10 and 20 )
)

insert #csv_split
exec( @sql )

select *
from #csv_split

end

-- this works fine
csv_eg ',11,12,13,14,,,,,,,,,,,,,,,'

-- these fail correctly because the data passed is not valid
csv_eg ',11,12,13,14,1,,,,,,,,,,,,,,'
csv_eg ',11,12,13,14,''ABC'',,,,,,,,,,,,,,'


How would you validate each one of those parameters? You would either have a
lot of IF ELSE statements, but that would be procedural and we all know your
view on using IF ELSE... or you could populate a talbe in the proc like I've
just done; only you'd have to do all the work manually, code all the
inserts, code all the parameters, test all the combinations - it's dinosaur
programming at best, something we'd do back in the 80's because languages
weren't as powerful as they are today (2007).

[quoted text, click to view]

Have you done any real programming?

You'd have 1,000 of these too....

cmdSQL = New SqlCommand("ihs.admin_meta_region_save", oDBConn)
cmdSQL.CommandType = CommandType.StoredProcedure

cmdSQL.Parameters.Add(New SqlParameter("@P0001", tbRegionNew.Text))

cmdSQL.Parameters.Add(New SqlParameter("@P0002", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))
cmdSQL.Parameters.Add(New SqlParameter("@P....", tbRegionNew.Text))

Joe Celko makes the following comment on passing a table as a
parameter
to a procedure:

[quoted text, click to view]

'Please read a book, any book, on data modeling, and RDBMS. A table
is an entity or a relationship. That would mean you have a magical,
super function that works on Squids, Automobiles, Britney Spears,
Geographical locations or anything in the whole of creation.'

But the super function, reusable functions, is precisely what modern
database developers should have at their disposable! And you can have
it:

http://beyondsql.blogspot.com/2007/08/dataphor-creating-super-function.html

It's also a chance to contrast the idea of a table as a variable,
'any'
table, with the mickey mouse idea of passing a table 'memory' variable
as being implemented in Katami. We are talking apples and oranges
folks :-)