• ScottPletcher (6/28/2016)


    Jeff Moden (6/28/2016)


    David92595 (6/28/2016)


    @Jeff

    Because I inherited this database and the person that made it thought in spreadsheets not relational tables.

    @scott

    Thank you! Are their any other good ways to stop a sql injection? My database, until recently, has been small and is still only internal so exposure to injections has been minimal. I know i need to get ahead of the curve on this though.

    David

    There's a possibility of making this almost brain-dead simple and totally SQL Injection proof and not require ANY dynamic SQL...

    If you ad a constraint to the state column of each table to force a limit on what can be in the table, you could create and updateable "Partitioned View" that would treat all of the related tables almost as if it were a single table. The view would need to have a hardcoded column for "state" for each table. That way you would pass the ID and the state and both would simply be included in the WHERE clause. No dynamic SQL needed at all.

    Hmm ... since the column name to be updated is passed in as well, you'd at least need to regenerate the view whenever the table schema changed.

    Ah, crud (no pun intended)... agreed. Forgot about the column name. Ya just gotta love "catch all" queries.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)