У меня есть этот запрос в моем источнике OLE DB с использованием параметра внутри него:
select *
from A
where A.A_DATE >= DATEADD(d,-1*(CAST(? as int)),GETDATE())
с использованием параметра X.Для примера я использую X = 1. Если я запускаю приведенный выше запрос в SQL Server Management Studio, он возвращает строку (правильную).Но когда я запускаю его в пакете служб SSIS, он не возвращает ни одной строки (что неверно).Если удалить -1 * xxx и перейти прямо к CAST (? Как int) (запрос выглядит так:)
select *
from A
where A.A_DATE >= DATEADD(d,CAST(? as int),GETDATE())
и установить значение X в -1, он показывает правильный результат (ряд вернулся).Что-то не так с умножением параметра с отрицательным значением в запросе источника OLE DB?
обновление 1: Кажется, есть другая проблема со вторым запросом, как будто я изменяю значение на 1, я все ещеполучить результаты строки (когда это не должно).Любые решения ??
обновление 2: кажется, что используется приведенное решение, также имеет недостатки, поскольку оно также не возвращает правильное значение.Я получал 2 возвращаемых строки, когда мне нужно было вернуть только 1 строку
Кажется, что вышеприведенный запрос также некорректен в SSIS, поэтому я решил использовать этот запрос, поэтому мне не нужно использовать CAST:
"select *
from A
where A.A_DATE >= DATEADD(d," + @[User::Y] + ",GETDATE())"
и поместите его в переменную (давайте назовем это Src_Query), а затем оцените приведенную выше строку как выражение.Я также использовал переменную Y с типом данных String вместо X с типом данных Int32, который я использовал ранее, и чтобы превратить ее в отрицательное значение, я просто использовал задачу сценария, чтобы справиться с ней.Затем в OLE DB Source я использовал опцию «Команда SQL из переменной».Я запустил пакет, и запрос вернул правильный результат.Это также полезно для переменных, которые я использовал внутри подзапросов.
Проблема с вышеприведенным решением: в моем проекте у меня есть исходный запрос, имеющий более 4000 символов, а SSIS не допускает более 4000символы, обработанные в построителе выражений.Все еще ищу способ обойти эту проблему.
Обновление 1: я обошел свою проблему для запроса длиной более 4000 символов, поместив предложение where в отдельное условное разбиение после извлечения данных, иЯ все еще могу использовать переменную, типизированную для Int32.
Это выражение, которое использовало условное разбиение, при этом запрос в источнике OLE DB больше не имеет предложения where, связанного с датой:
A_DATE >= DATEADD("d",@[User::X],(DT_DBDATE)GETDATE())
Интересно, а как это повлияет на производительность? Значительно ли это?