August 9, 2012 at 1:38 pm
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
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
August 9, 2012 at 2:46 pm
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
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
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?
August 10, 2012 at 8:30 am
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
ok how about this idea:
if you grab the free, add-on SSMS Tools
from here:
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
August 10, 2012 at 8:52 am
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