![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
#3
| |||
| |||
|
|
Yeah, I figured that after spending a few hours on using these parameters in the query window. I did create an sp and passed the parameters, which worked. I am bummed that it wouldn't work unless you wrap the code in an sp! I have lots of such DTS packages we ran every month/quarter so dates parameter are always there with UNION and joins so always needing to change the dates at numerous places at each run, which is why I thought of using parameter, but it didn't work the way I wanted so I guess I'll need to convert each SQL into an SP. The statement in my post referenced dates at 18 different places so you could see how time consuming and frustrating the task of changing dates can be each time the package is run if there isn't a global variable/parameter to take of these changing value. If anyone else has a better solution to this (other than SQL code wrapped in SP), please let me know. |
#4
| |||
| |||
|
|
DTJ, I already have a table with only dates in it and yes, I tried that, too, but it failed in my situation (in the source query in Transform Data Task window). The only thing that has worked so far is the SP route. Your suggestion does work if a query is to run on Enterprise Manager's Query Builder or Query Analyzer, but not in Source tab of Data Transform Properties within a DTS package. It gives error regarding violation and some other such things. So it seems using sp is the only way to use variables in this kind of situation. Note that the dates are same through out the code, but due to numerous Unions, the same dates need to be repeated 18+ times on different UNION statements’ WHERE clause, which is why I wanted to use a variable. This query is about 5 pages long! Thanks all for your help. |
#5
| |||
| |||
|
|
Yeah, I figured that after spending a few hours on using these parameters in the query window. I did create an sp and passed the parameters, which worked. I am bummed that it wouldn't work unless you wrap the code in an sp! I have lots of such DTS packages we ran every month/quarter so dates parameter are always there with UNION and joins so always needing to change the dates at numerous places at each run, which is why I thought of using parameter, but it didn't work the way I wanted so I guess I'll need to convert each SQL into an SP. The statement in my post referenced dates at 18 different places so you could see how time consuming and frustrating the task of changing dates can be each time the package is run if there isn't a global variable/parameter to take of these changing value. If anyone else has a better solution to this (other than SQL code wrapped in SP), please let me know. |
![]() |
| Thread Tools | |
| Display Modes | |
| |