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
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/dynamic_sql.html#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 [quoted text, click to view] adrian@heywood.com.au (adrian) wrote in message news:<19ef5f9f.0307072230.2ee3c9e3@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
[posted and mailed, please reply in news] adrian (adrian@heywood.com.au) writes: [quoted text, click to view] > 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. [quoted text, click to view] > 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/dynamic_sql.html#sp_executesql for details. -- Erland Sommarskog, SQL Server MVP, sommar@algonet.se Books Online for SQL Server SP3 at
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 [quoted text, click to view] "adrian" <adrian@heywood.com.au> wrote in message news:19ef5f9f.0307072230.2ee3c9e3@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.
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 ***
Adrian Hoess (anonymous@devdex.com) writes: [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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, sommar@algonet.se Books Online for SQL Server SP3 at
Don't see what you're looking for? Try a search.
|