Post reply

CRUD generator

  • June 27, 2009 at 3:23 pm

    #207683

    Comments posted to this topic are about the item CRUD generator

  • July 6, 2009 at 12:22 pm

    #1020557

    Getting an error:

    declare @TableName varchar(100)

    ,@SQL1 varchar(2000)

    ,@SQL2 varchar(2000)

    ,@SQL3 varchar(2000)

    ,@SQL4 varchar(2000)

    ,@SQL5 varchar(2000)

    ,@SQL6 varchar(2000)

    ,@Parameters int

    ,@TypeOfCrud int--1 = Insert, 2 = Update, 3 = Read, 4 = Delete, 5 = All

    select @TableName = 'CUSTOMER_ORDER' --<<Enter the name of the table

    ,@Parameters = 0 --<< If using parameters for the insert statement then use 1 if not then use 0

    ,@TypeOfCrud = 3

    As you can see, I chose a table from my database, "read" type, and get I get this error at the exec(@SQL1) statement and exec(@SQL@) statements:

    Msg 197, Level 15, State 1, Line 235

    EXECUTE cannot be used as a source when inserting into a table variable.

    Msg 197, Level 15, State 1, Line 241

    EXECUTE cannot be used as a source when inserting into a table variable.

    if isnull(@SQL1, '') ''

    begin

    insert into @FinalSelect([--SelectText])

    exec (@SQL1)

    if isnull(@SQL2, '') ''

    begin

    insert into @FinalSelect([--SelectText])

    exec(@SQL2)

    end

  • July 6, 2009 at 2:59 pm

    #1020671

    What version of SQL Server are you using?

    This was coded on SQL Server 2005.

    I never encountered this error; however, I would simply change the @FinalSelect table variable to a temp table #FinalSelect and try that.

    Thanks,

    Ryan Foote

  • July 6, 2009 at 5:01 pm

    #1020768

    Thanks for the contribution. Most of the time I encourage the use of object abstraction tools like mygeneration, entity space, etc., but its always nice to have some tools available.

    The more you are prepared, the less you need it.

  • July 6, 2009 at 5:32 pm

    #1020777

    [font="Verdana"]While I like the idea of using code generators for tasks like this, I do have an issue with the approach of recommending a row-by-row interface.

    Also, the typical CRUD interface is at a table level, rather than at an "object" level. For example, you will have one part of the interface for the invoice_header, and another for the invoice_line. To me a better approach is to create an interface that takes many invoices, and have the database code written at that level. It can then use set-based logic.

    I don't believe that database interfaces require a row-by-row approach, or that they have to be formed around the physical tables. So use with caution.

    [/font]

  • May 24, 2016 at 7:01 am

    #1881062

    Thanks for the script.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply