using text data type in dynamic sql sproc

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • adrian

    using text data type in dynamic sql sproc

    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 [procArticlesIns ert]
    (
    @siteID [int],
    @strShortTitle [varchar](40),
    @strLongTitle [varchar](60),
    @strShortConten t [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 + ''', ' +
    '''' @strShortConten t , ' +
    ' @strLongContent , ' +
    CAST(@intSectio nID AS VARCHAR) + ', ' +
    CAST(@intTempla teID AS VARCHAR) + ', ' +
    CAST(@intStatus ID AS VARCHAR) + ')')
    GO

    i could cast the text fields (@strShortConte nt , @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

    #2
    Re: using text data type in dynamic sql sproc

    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
    Se våra kampanjer på mobiler, abonnemang och tv- och streampaket | Telenor



    John

    "adrian" <adrian@heywood .com.au> wrote in message
    news:19ef5f9f.0 307072230.2ee3c 9e3@posting.goo gle.com...[color=blue]
    > 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 [procArticlesIns ert]
    > (
    > @siteID [int],
    > @strShortTitle [varchar](40),
    > @strLongTitle [varchar](60),
    > @strShortConten t [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 + ''', ' +
    > '''' @strShortConten t , ' +
    > ' @strLongContent , ' +
    > CAST(@intSectio nID AS VARCHAR) + ', ' +
    > CAST(@intTempla teID AS VARCHAR) + ', ' +
    > CAST(@intStatus ID AS VARCHAR) + ')')
    > GO
    >
    > i could cast the text fields (@strShortConte nt , @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.[/color]


    Comment

    • Erland Sommarskog

      #3
      Re: using text data type in dynamic sql sproc

      [posted and mailed, please reply in news]

      adrian (adrian@heywood .com.au) writes:[color=blue]
      > 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.[/color]

      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.
      [color=blue]
      > everything seems to work fine until i try and manipulate a parameter
      > which is of text data type.[/color]

      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, sommar@algonet. se

      Books Online for SQL Server SP3 at
      SQL Server 2025 redefines what's possible for enterprise data. With developer-first features and integration with analytics and AI models, SQL Server 2025 accelerates AI innovation using the data you already have.

      Comment

      • Simon Hayes

        #4
        Re: using text data type in dynamic sql sproc

        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:



        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

        adrian@heywood. com.au (adrian) wrote in message news:<19ef5f9f. 0307072230.2ee3 c9e3@posting.go ogle.com>...[color=blue]
        > 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 [procArticlesIns ert]
        > (
        > @siteID [int],
        > @strShortTitle [varchar](40),
        > @strLongTitle [varchar](60),
        > @strShortConten t [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 + ''', ' +
        > '''' @strShortConten t , ' +
        > ' @strLongContent , ' +
        > CAST(@intSectio nID AS VARCHAR) + ', ' +
        > CAST(@intTempla teID AS VARCHAR) + ', ' +
        > CAST(@intStatus ID AS VARCHAR) + ')')
        > GO
        >
        > i could cast the text fields (@strShortConte nt , @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.[/color]

        Comment

        • Adrian Hoess

          #5
          Re: using text data type in dynamic sql sproc

          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_procArticlesI nsert], 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!

          Comment

          • Erland Sommarskog

            #6
            Re: using text data type in dynamic sql sproc

            Adrian Hoess (anonymous@devd ex.com) writes:[color=blue]
            > 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)[/color]

            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.
            [color=blue]
            > ii) i did not really have to change much of the data acces logic other
            > than add in a siteID to the existing procs.[/color]

            The same would apply if you put the siteID as a table column.
            [color=blue]
            > 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][/color]

            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
            SQL Server 2025 redefines what's possible for enterprise data. With developer-first features and integration with analytics and AI models, SQL Server 2025 accelerates AI innovation using the data you already have.

            Comment

            Working...