Нужна помощь ребятам.Альтернатива динамическому запросу в SSRS
У меня есть хранимая процедура, которая отображает все записи.
SELECT
Entity.Name as [ENTITY],
Product.Name AS [Product Name],
convert(date, whseintg.TrnDate) as TrnDate,
DOGR.AppNo,
DOGR.TrnNo,
DOGR.TrnType,
DOGR.StkId,
DOGR_D.ProdId,
DOGR_D.Qty,
DOGR_D.QtyIn,
DOGR_D.UPrice,
Ratio.Ratio
FROM Entity WITH (NOLOCK),
Product WITH (NOLOCK),
DOGR WITH (NOLOCK),
DOGR_D WITH (NOLOCK),
Ratio WITH (NOLOCK),
whseintg WITH (Nolock)
WHERE (DOGR_D.ProdId = Product.ProdId) and
(DOGR.TrnType = DOGR_D.TrnType) and
(DOGR.AppNo = DOGR_D.AppNo) and
(DOGR_D.RatioId = Ratio.Ratioid) and
(DOGR.TrnType = whseintg.TrnType) and
(DOGR.Appno = whseintg.TrnNo) and
(DOGR.TrnNo is not null) and
((dbo.DOGR.TrnType = 'SCR')) and
(dbo.DOGR.LocID = dbo.Entity.LocID)
Теперь у меня есть определенные параметры, такие как @FromProductName
и @ToProductName
в режиме конструктора отчета.
Я не хочу использовать динамические запросы, потому что это будет иметь влияние на производительность приложения. То, что я хочу, что если есть значение, передаваемое в обоих переменных, то запрос будет что-то вроде этого:
SELECT
Entity.Name as [ENTITY],
Product.Name AS [Product Name],
convert(date, whseintg.TrnDate) as TrnDate,
DOGR.AppNo,
DOGR.TrnNo,
DOGR.TrnType,
DOGR.StkId,
DOGR_D.ProdId,
DOGR_D.Qty,
DOGR_D.QtyIn,
DOGR_D.UPrice,
Ratio.Ratio
FROM Entity WITH (NOLOCK),
Product WITH (NOLOCK),
DOGR WITH (NOLOCK),
DOGR_D WITH (NOLOCK),
Ratio WITH (NOLOCK),
whseintg WITH (Nolock)
WHERE (DOGR_D.ProdId = Product.ProdId) and
(DOGR.TrnType = DOGR_D.TrnType) and
(DOGR.AppNo = DOGR_D.AppNo) and
(DOGR_D.RatioId = Ratio.Ratioid) and
(DOGR.TrnType = whseintg.TrnType) and
(DOGR.Appno = whseintg.TrnNo) and
(DOGR.TrnNo is not null) and
((dbo.DOGR.TrnType = 'SCR')) and
(dbo.DOGR.LocID = dbo.Entity.LocID)
and (DOGR_D.ProdId between @FromProdID and @ToProdID)
Иначе, он будет вести себя как оригинальный запрос. Это возможно?
И, пожалуйста, прекратите использование неявного синтаксиса. Это очень плохая техника прогромма, которая легко приведет к неправильным результатам или случайным кросс-соединениям, потому что записи объединений пробиваются из объединений. FUrther, если вам нужно перейти на левое соединение, вам нужно переписать всю qwuery, потому что вы никогда не должны смешивать явное и неявное объединение или вы, скорее всего, получите неправильный ответ. В сложных запросах отчетности это особенно плохая практика, так как у вас, вероятно, будет много объединений. Этот синтаксис был заменен 20 лет назад, почему вы даже рассматриваете его использование? – HLGEM