Post reply

Equivalent to "#INCLUDE" Preprocessor Directive in T-SQL?

  • August 9, 2012 at 1:38 pm

    #260581

    In C and C++ there is a preprocessor directive (#INCLUDE <fileX>) you can place into your source code files which results in the compiler treating <fileX> as if it is present in your source file at the location of the #INCLUDE at compile time. I am wondering - is there an equivalent to this directive in T-SQL?

    In the case of me and my team, we have a large set of variables that are common to a number of SQL script files we are developing. Instead of defining and setting the variables with the same statements in every one of those SQL scripts I'd like to have a single text file, accessible to all the SQL scripts, which could be read into each of the scripts via a single line (something like the #INCLUDE) whenever the script is executed.

    I don't know if my explanation is clear (I can clarify or provide examples if needed). Thanks in advance for any help.

    Regards,

    Jose

  • August 9, 2012 at 1:51 pm

    #1524078

    there is no equivilent; each SQL statements kind of assumed to stand alone, and would need everything it needs inline with the command itself, sorry.

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • August 9, 2012 at 2:46 pm

    #1524128

    Thank you, Lowell. I am disappointed but not surprised. I had scoured the T-SQL reference I had prior to posting here and had not seen any reference to anything which might serve as the equivalent of the #INCLUDE. I thought that if anyone would know for certain, though, it would be the folks here. 🙂

    I appreciate your help,

    José

  • August 9, 2012 at 9:50 pm

    #1524192

    If you run your scripts in sqlcmd mode in ssms or using sqlcmd.exe, you can use :r to import files into the current script.

  • August 10, 2012 at 7:01 am

    #1524403

    I might be thinking outloud and it could be even more work, but is an idea.

    Could you use a stored procedure that will assign all those values to output parameters? Or use a table-value function to assign them?

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2

  • August 10, 2012 at 8:30 am

    #1524470

    Those are some great suggestions - thanks. I had toyed with the idea about possibly using a stored procedure previously but hadn't really explored it in any detail. A table-valued function is something I haven't worked with before. From what I have read about them, I suspect (but am not positive) that they will require as much or more code than what I'm doing now, but that's an off-the-cuff thought. I do want to explore those ideas more, though, because I think both of them can help me with some other things I need to do.

    As for the SQLCMD idea, I wasn't familiar with the :r option, so I'll have to do some research. Offhand, it sounds like it would do the trick. We typically execute our SQL scripts from within the Management Studio, but there's no particular reason why we have to.

    Should make for some interesting days ahead while I play with those ideas. 🙂 Again, thank you!

    José

  • August 10, 2012 at 8:36 am

    #1524477

    ok how about this idea:

    if you grab the free, add-on SSMS Tools

    from here:

    http://www.ssmstoolspack.com/

    one of the options it provides is a "default" template every time you create a new query window in SSMS.

    you could make the template contain all your desired variables as part of the default.

    maybe even comment them with /* */, so they are there, and if you need them just uncomment the header info.

    my template just has a transaction in it with commit/rollback commented out, but yours could be howerver works for you.

    SET XACT_ABORT ON

    BEGIN TRAN

    --ROLLBACK TRAN

    --COMMIT TRAN

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • August 10, 2012 at 8:52 am

    #1524490

    Jose Johnson (8/10/2012)

    Those are some great suggestions - thanks. I had toyed with the idea about possibly using a stored procedure previously but hadn't really explored it in any detail. A table-valued function is something I haven't worked with before. From what I have read about them, I suspect (but am not positive) that they will require as much or more code than what I'm doing now, but that's an off-the-cuff thought. I do want to explore those ideas more, though, because I think both of them can help me with some other things I need to do.

    As for the SQLCMD idea, I wasn't familiar with the :r option, so I'll have to do some research. Offhand, it sounds like it would do the trick. We typically execute our SQL scripts from within the Management Studio, but there's no particular reason why we have to.

    Should make for some interesting days ahead while I play with those ideas. 🙂 Again, thank you!

    José

    In SSMS, open a new query window, Menu -> Query -> SQLCMD Mode

Viewing 8 posts - 1 through 7 (of 7 total)

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