using text data type in dynamic sql sproc

[adrian]

hi all

this is my first post to this group, so pls bear with me while i try
to make some sense.

i am trying to create a sproc which uses dynamic sql to target a
particuar table eg. '[dbo].[' + @tableID + '_articles']' and perform
some actions.

i am using @tableID [int] as a passes parameter for the sproc.

everything seems to work fine until i try and manipulate a parameter
which is of text data type.

the error occurs when i try to build the dynamic sql string and append
the text type variable.

eg.

CREATE PROCEDURE [procArticlesInsert]
(
@siteID [int],
@strShortTitle [varchar](40),
@strLongTitle [varchar](60),
@strShortContent [text],
@strLongContent [text],
@intSectionID [int],
@intTemplateID [int],
@intStatusID [int]
)

AS

DECLARE @strSQL varchar (1000)
DECLARE @strSiteID varchar (10)
SET @strSiteID = CAST(@siteID AS varchar)

SET @strSQL = ('INSERT INTO [' + @strSiteID + '_articles] ' +
' ( [dateEntered], ' +
' [shortTitle], ' +
' [longTitle], ' +
' [shortContent], ' +
' [longContent], ' +
' [sectionID], ' +
' [templateID], ' +
' [statusID]) ' +
'VALUES ' +
' (' + CAST(GETDATE() AS VARCHAR) + ', ' +
'''' + @strShortTitle + ''', ' +
'''' + @strLongTitle + ''', ' +
'''' @strShortContent , ' +
' @strLongContent , ' +
CAST(@intSectionID AS VARCHAR) + ', ' +
CAST(@intTemplateID AS VARCHAR) + ', ' +
CAST(@intStatusID AS VARCHAR) + ')')
GO

i could cast the text fields (@strShortContent , @strLongContent) to
varchar, but the restriction of 8000 characters will not go down so
nicely.

if anyone has any ideas or alternatives to what i am trying to
achieve, i would love to hear from you.

thanks
adrian.

[John Bell]

Hi

As @strSQL is only varchar(1000) I am not sure why you think you can append
a text column even if converted to varchar(8000)!

Check out http://www.algonet.se/~sommar/dynamic_sql.html and
http://www.algonet.se/~sommar/dyn-search.html
John

"adrian" <ad****@heywood.com.au> wrote in message
news:19**************************@posting.google.c om...

hi all

this is my first post to this group, so pls bear with me while i try
to make some sense.

i am trying to create a sproc which uses dynamic sql to target a
particuar table eg. '[dbo].[' + @tableID + '_articles']' and perform
some actions.

i am using @tableID [int] as a passes parameter for the sproc.

everything seems to work fine until i try and manipulate a parameter
which is of text data type.

the error occurs when i try to build the dynamic sql string and append
the text type variable.

eg.

CREATE PROCEDURE [procArticlesInsert]
(
@siteID [int],
@strShortTitle [varchar](40),
@strLongTitle [varchar](60),
@strShortContent [text],
@strLongContent [text],
@intSectionID [int],
@intTemplateID [int],
@intStatusID [int]
)

AS

DECLARE @strSQL varchar (1000)
DECLARE @strSiteID varchar (10)
SET @strSiteID = CAST(@siteID AS varchar)

SET @strSQL = ('INSERT INTO [' + @strSiteID + '_articles] ' +
' ( [dateEntered], ' +
' [shortTitle], ' +
' [longTitle], ' +
' [shortContent], ' +
' [longContent], ' +
' [sectionID], ' +
' [templateID], ' +
' [statusID]) ' +
'VALUES ' +
' (' + CAST(GETDATE() AS VARCHAR) + ', ' +
'''' + @strShortTitle + ''', ' +
'''' + @strLongTitle + ''', ' +
'''' @strShortContent , ' +
' @strLongContent , ' +
CAST(@intSectionID AS VARCHAR) + ', ' +
CAST(@intTemplateID AS VARCHAR) + ', ' +
CAST(@intStatusID AS VARCHAR) + ')')
GO

i could cast the text fields (@strShortContent , @strLongContent) to
varchar, but the restriction of 8000 characters will not go down so
nicely.

if anyone has any ideas or alternatives to what i am trying to
achieve, i would love to hear from you.

thanks
adrian.

[Erland Sommarskog]

[posted and mailed, please reply in news]

adrian (ad****@heywood.com.au) writes:

i am trying to create a sproc which uses dynamic sql to target a
particuar table eg. '[dbo].[' + @tableID + '_articles']' and perform
some actions.

i am using @tableID [int] as a passes parameter for the sproc.
Could you give the rationale for this design? Would it not be better
to have this "tableiD" as a key in the table?

Dynamically created tables are not in the lines of thinking with the
relational data model.
everything seems to work fine until i try and manipulate a parameter
which is of text data type.

Rather than building a complete string and get lost in a maze of quotes
(do you realize that your procedure will throw up, if some one passes
"O'Brien" in one of the input parameters), use sp_executesql instead.
See http://www.algonet.se/~sommar/dynami...#sp_executesql for
details.
--
Erland Sommarskog, SQL Server MVP, so****@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Simon Hayes]

The short answer is that you can't do this in the way you're trying to
- @strSQL is varchar(1000), so the total length of the INSERT
statement including data can't be more than that. Obviously, the text
parameter values alone may be much longer.

The best solution, if possible, is almost certainly to remodel your
tables, putting all the articles into a single table, with SiteID as a
column. By doing this, you wouldn't need any dynamic SQL at all, and
it's also a better data model. I appreciate that this may not be easy
in your environment, depending on how much or how little control you
have over the database, how much existing code you have etc. See this
link:

http://www.algonet.se/~sommar/dynami...tml#Sales_yymm

If you can't change the data model, then one alternative is to build
an INSERT string dynamically in your client application - it's often
easier to do it there than in the database.

Simon

ad****@heywood.com.au (adrian) wrote in message news:<19**************************@posting.google. com>...

hi all

this is my first post to this group, so pls bear with me while i try
to make some sense.

i am trying to create a sproc which uses dynamic sql to target a
particuar table eg. '[dbo].[' + @tableID + '_articles']' and perform
some actions.

i am using @tableID [int] as a passes parameter for the sproc.

everything seems to work fine until i try and manipulate a parameter
which is of text data type.

the error occurs when i try to build the dynamic sql string and append
the text type variable.

eg.

CREATE PROCEDURE [procArticlesInsert]
(
@siteID [int],
@strShortTitle [varchar](40),
@strLongTitle [varchar](60),
@strShortContent [text],
@strLongContent [text],
@intSectionID [int],
@intTemplateID [int],
@intStatusID [int]
)

AS

DECLARE @strSQL varchar (1000)
DECLARE @strSiteID varchar (10)
SET @strSiteID = CAST(@siteID AS varchar)

SET @strSQL = ('INSERT INTO [' + @strSiteID + '_articles] ' +
' ( [dateEntered], ' +
' [shortTitle], ' +
' [longTitle], ' +
' [shortContent], ' +
' [longContent], ' +
' [sectionID], ' +
' [templateID], ' +
' [statusID]) ' +
'VALUES ' +
' (' + CAST(GETDATE() AS VARCHAR) + ', ' +
'''' + @strShortTitle + ''', ' +
'''' + @strLongTitle + ''', ' +
'''' @strShortContent , ' +
' @strLongContent , ' +
CAST(@intSectionID AS VARCHAR) + ', ' +
CAST(@intTemplateID AS VARCHAR) + ', ' +
CAST(@intStatusID AS VARCHAR) + ')')
GO

i could cast the text fields (@strShortContent , @strLongContent) to
varchar, but the restriction of 8000 characters will not go down so
nicely.

if anyone has any ideas or alternatives to what i am trying to
achieve, i would love to hear from you.

thanks
adrian.

[Adrian Hoess]

hi all thanks for the replies and direction.

the main reason why i chose to use dynamic sql as opposed to inserting a
tableid column was because:

i) i thought there would be decrease in performance if there were alot
of record in one table. (eg if the user runs 100 sites with 1000 record
in each)

ii) i did not really have to change much of the data acces logic other
than add in a siteID to the existing procs.

iii) i figured the information would be stored in a more organised
fashion as each new set of tables will represent a site in a multisite
cms eg. [n_articles]

i now understand that my approach is not as easy (or efficient) as i
first thought, and many unseen traps and future maintenance issues with
the implementation of dyn sql.

firstly i need to ask if my first assumption is true? is there a
relationship b/t # of records in a table and performance of the db when
making references to that table?

I could alternatively create a set of stored procedures for each site
[n_procArticlesInsert], this way I will not need to use dynamic object
names, and will require the least amount of revision to the data and
business logic. Are there any forseen downsides to this?

thanks.
adrian

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Erland Sommarskog]

Adrian Hoess (an*******@devdex.com) writes:

i) i thought there would be decrease in performance if there were alot
of record in one table. (eg if the user runs 100 sites with 1000 record
in each)
There are occasions when this is a viable concern. When you have some
100 million rows in total. Mainly because you want to spread out the table
on different disks and that. Even if you do this, there is still a way
to use the table as a whole, by uniting the tables in a partitioned view.
But this is an advance feature, and with a mere 100000 rows, don't even
think about it.

SQL Server, as any enterprise RDBMS, is designed to handle large amount
of data. It is not designed to handle tables that are created dynamically.
It can handle it, but as you will find, your programming gets more
complicated. And performance usually decreases.

What is important, though, is to have proper indexes on your tables.
ii) i did not really have to change much of the data acces logic other
than add in a siteID to the existing procs.
The same would apply if you put the siteID as a table column.
iii) i figured the information would be stored in a more organised
fashion as each new set of tables will represent a site in a multisite
cms eg. [n_articles]

I'm not sure that I see the relevance of this. A table is a set, and from
a set you can always define a subset. SELECT * FROM tbl WHERE site = @site
is a table which holds the data for one site.

Say that for some reason you need to do a cross-site search. How are you
going to do that it you have one set of tables per site? With one big
table, this is a snap.
--
Erland Sommarskog, SQL Server MVP, so****@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp