Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
Почему запрос выполняется так долго? Если из запроса убрать хотя бы одно ограничение, то время выполнения запроса будет менее секунды. Как с этим бороться? MS SQL 2016

SELECT [t0].*
FROM [dbo].[WorkshopRoad] AS [t0]
INNER JOIN [dbo].[ClaimStrAssembly] AS [t1] ON [t1].[PkClaimStrAssembly] = [t0].[FkClaimStrAssembly]
INNER JOIN [dbo].[ClaimStr] AS [t2] ON [t2].[PkClaimStr] = [t1].[FkClaimStr]
INNER JOIN [dbo].[Claim] AS [t3] ON [t3].[PkClaim] = [t2].[FkClaim]
WHERE 
	(([t2].[FkProduct] = @p2) OR ([t3].[OtklNumberProduct] = 1)) 
	AND ([t2].[FkClaim] = @p3) 
	AND  ([t1].[FkProduct] = @p0) 
	AND ([t0].[FkWorkshop] = @p1) 
	AND ([t1].[Quantity] > @p4)


К сообщению приложен файл. Размер - 36Kb
22 мар 18, 06:49    [21276095]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
aleksrov
Member

Откуда:
Сообщений: 948
ExB,

Прикольно 4 ляма процентов :)
Обновите статистику, посмотрите на план, вас не смущает что у вас к примеру в первом Nested Loop слева ожидаемое кол-во строк 797, фактическое 35 лямов. Или у вас parametr sniffing.
Когда вы убераете одно из условий из where в принципе вполне логично, что у вас выполняется быстрее. В select вы выбираете только данные из t0, стлбцы остальных таблиц используются только в join и where, вполне вероятно что убрав к примеру t1].[Quantity] > @p4, SQL способен использовать индекс котрый наверника есть на [t1].[FkProduct], также вполне вероятно что убрав какое-либо условие, т.е. у вас таблица используется только в Join, SQL может применить Simplification при оптимизации, т.е. если у вас есть две таблица и есть FK, SQL и так знает что для каждой строки в таблицы "приемнике" есть строка в таблице "родителе" и просто не будет ее даже читать когда вы делаете inner join по этим столбцам. Но это отступление, у вас основное конечно факт и ожидание разнятся просто колоссально.
22 мар 18, 08:05    [21276125]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
aleksrov, вот эти 4 ляма процентов меня очень смущают.
Статистика обновляется каждую ночь при создании бэкапа. Ручное обновление статистики не дает результата.
UPDATE STATISTICS [Claim]
UPDATE STATISTICS [ClaimStr]
UPDATE STATISTICS [ClaimStrAssembly]
UPDATE STATISTICS [WorkshopRoad]
22 мар 18, 09:11    [21276208]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
aleksrov
Member

Откуда:
Сообщений: 948
ExB,

Тогда выложите сюда этот план.
22 мар 18, 09:13    [21276213]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
vborets
Member

Откуда:
Сообщений: 164
ExB,

А если условия засунуть в JOIN ?
22 мар 18, 10:29    [21276389]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
vborets
ExB,

А если условия засунуть в JOIN ?

это всё менят

OPTION(RECOMPILE) или план не картинкой
22 мар 18, 10:39    [21276425]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2421
ExB
aleksrov, вот эти 4 ляма процентов меня очень смущают.
Статистика обновляется каждую ночь при создании бэкапа. Ручное обновление статистики не дает результата.
UPDATE STATISTICS [Claim]
UPDATE STATISTICS [ClaimStr]
UPDATE STATISTICS [ClaimStrAssembly]
UPDATE STATISTICS [WorkshopRoad]


а если обновить полностью with fullscan ?
Очень уже похоже на криву статистику.
22 мар 18, 11:35    [21276616]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
aleksrov
Member

Откуда:
Сообщений: 948
WarAnt,

Не, скорее всего sniffing. Разница между 800 и 35 лямов уж совсем большая.
22 мар 18, 11:45    [21276658]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
ExB,

Для начала попробуйте заменить все переменные на константы и посмотрите на ожидаемое vs реальное количество строк.
23 мар 18, 00:28    [21279194]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
А план такой:

К сообщению приложен файл. Размер - 31Kb
23 мар 18, 03:34    [21279238]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
При замене переменных @p3 или @p1 на константы запрос выполняется мгновенно. При замене остальных переменных на константы изменений не замечено.
23 мар 18, 03:40    [21279240]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
Вот такая статистика запросов если @p1 заменить на константу:
(извиняюсь за широкоформатные изображения)

К сообщению приложен файл. Размер - 52Kb
23 мар 18, 03:52    [21279242]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
TaPaK
vborets
ExB,

А если условия засунуть в JOIN ?

это всё менят

OPTION(RECOMPILE) или план не картинкой

OPTION(RECOMPILE)
23 мар 18, 08:42    [21279418]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7392
Всегда было интересно - что имеется в виду под "фактическим"? На выборы пришло 110% населения?
23 мар 18, 13:15    [21280533]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
nvv
Member

Откуда:
Сообщений: 54
ExB,
Перепишите соединения на вложенные и добавьте условия в соединение.
Исчезнут nested loops и все будет работать мгновенно.
23 мар 18, 19:58    [21281954]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
nvv
ExB,
Перепишите соединения на вложенные и добавьте условия в соединение.
Исчезнут nested loops и все будет работать мгновенно.

очень врядли. Такие простые условия соединения оптимизатор сам переставит как сочтет нужным
23 мар 18, 23:00    [21282264]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1667
А если так?

SELECT [t0].*
FROM
(
	Select *
	From [dbo].[WorkshopRoad] 
	Where [FkWorkshop] = @p1
) AS [t0]
INNER JOIN 
(select [PkClaimStrAssembly]
from [dbo].[ClaimStrAssembly]
where [FkProduct] = @p0 AND [Quantity] > @p4
) AS [t1] 
ON [t0].[FkClaimStrAssembly]=[t1].[PkClaimStrAssembly]
INNER JOIN 
(select [PkClaimStr],[FkClaim],[FkProduct]
from [dbo].[ClaimStr]
where [t2].[FkClaim] = @p3
) AS [t2] ON [t1].[FkClaimStr]=[t2].[PkClaimStr]  
INNER JOIN [dbo].[Claim] AS [t3] ON [t2].[FkClaim]=[t3].[PkClaim]
WHERE 
	(([t2].[FkProduct] = @p2) OR ([t3].[OtklNumberProduct] = 1)) 
23 мар 18, 23:52    [21282339]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
nvv
ExB,
Перепишите соединения на вложенные и добавьте условия в соединение.
Исчезнут nested loops и все будет работать мгновенно.

впечатляет
24 мар 18, 10:54    [21282670]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
OPTION(RECOMPILE)
Rows	Executes	StmtText	StmtId	NodeId	Parent	PhysicalOp	LogicalOp	Argument	DefinedValues	EstimateRows	EstimateIO	EstimateCPU	AvgRowSize	TotalSubtreeCost	OutputList	Warnings	Type	Parallel	EstimateExecutions
0 1 SELECT [t0].* FROM [dbo].[WorkshopRoad] AS [t0] INNER JOIN [dbo].[ClaimStrAssembly] AS [t1] ON [t1].[PkClaimStrAssembly] = [t0].[FkClaimStrAssembly] INNER JOIN [dbo].[ClaimStr] AS [t2] ON [t2].[PkClaimStr] = [t1].[FkClaimStr] INNER JOIN [dbo].[Claim] AS [t3] ON [t3].[PkClaim] = [t2].[FkClaim] WHERE (([t2].[FkProduct] = @p2) OR ([t3].[OtklNumberProduct] = 1)) AND ([t2].[FkClaim] = @p3) AND ([t1].[FkProduct] = @p0) AND ([t0].[FkWorkshop] = @p1) AND ([t1].[Quantity] > @p4) OPTION(RECOMPILE) 1 1 0 NULL NULL NULL NULL 1 NULL NULL NULL 11,48078 NULL NULL SELECT 0 NULL
0 1 |--Nested Loops(Inner Join, WHERE:([Asupr].[dbo].[ClaimStr].[FkProduct] as [t2].[FkProduct]=(28178851) OR [Asupr].[dbo].[Claim].[OtklNumberProduct] as [t3].[OtklNumberProduct]=(1))) 1 2 1 Nested Loops Inner Join WHERE:([Asupr].[dbo].[ClaimStr].[FkProduct] as [t2].[FkProduct]=(28178851) OR [Asupr].[dbo].[Claim].[OtklNumberProduct] as [t3].[OtklNumberProduct]=(1)) NULL 1 0 4,18E-06 117 11,48078 [t0].[PkWorkshopRoad], [t0].[FkWorkshop], [t0].[FkClaimStrAssembly], [t0].[QuantityMade], [t0].[Quantity], [t0].[QuantityReady], [t0].[QuantityDefect], [t0].[QuantityKd], [t0].[Num], [t0].[Kind], [t0].[QuantityPdo], [t0].[QuantityMadeUnload], [t0].[QuantityCorrect], [t0].[QuantityMadeWorkshop] NULL PLAN_ROW 0 1
1 1 |--Clustered Index Seek(OBJECT:([Asupr].[dbo].[Claim].[KeyPkClaim] AS [t3]), SEEK:([t3].[PkClaim]=(27331859)) ORDERED FORWARD) 1 3 2 Clustered Index Seek Clustered Index Seek OBJECT:([Asupr].[dbo].[Claim].[KeyPkClaim] AS [t3]), SEEK:([t3].[PkClaim]=(27331859)) ORDERED FORWARD [t3].[OtklNumberProduct] 1 0,003125 0,0001581 9 0,0032831 [t3].[OtklNumberProduct] NULL PLAN_ROW 0 1
0 1 |--Parallelism(Gather Streams) 1 4 2 Parallelism Gather Streams NULL NULL 1 0 0,0285165 125 11,47749 [t0].[PkWorkshopRoad], [t0].[FkWorkshop], [t0].[FkClaimStrAssembly], [t0].[QuantityMade], [t0].[Quantity], [t0].[QuantityReady], [t0].[QuantityDefect], [t0].[QuantityKd], [t0].[Num], [t0].[Kind], [t0].[QuantityPdo], [t0].[QuantityMadeUnload], [t0].[QuantityCorrect], [t0].[QuantityMadeWorkshop], [t2].[FkProduct] NULL PLAN_ROW 1 1
0 12 |--Hash Match(Inner Join, HASH:([t1].[PkClaimStrAssembly])=([t0].[FkClaimStrAssembly]), RESIDUAL:([Asupr].[dbo].[ClaimStrAssembly].[PkClaimStrAssembly] as [t1].[PkClaimStrAssembly]=[Asupr].[dbo].[WorkshopRoad].[FkClaimStrAssembly] as [t0].[FkClaimStrAssembly])) 1 5 4 Hash Match Inner Join HASH:([t1].[PkClaimStrAssembly])=([t0].[FkClaimStrAssembly]), RESIDUAL:([Asupr].[dbo].[ClaimStrAssembly].[PkClaimStrAssembly] as [t1].[PkClaimStrAssembly]=[Asupr].[dbo].[WorkshopRoad].[FkClaimStrAssembly] as [t0].[FkClaimStrAssembly]) NULL 1 0 0,01775669 125 11,44897 [t0].[PkWorkshopRoad], [t0].[FkWorkshop], [t0].[FkClaimStrAssembly], [t0].[QuantityMade], [t0].[Quantity], [t0].[QuantityReady], [t0].[QuantityDefect], [t0].[QuantityKd], [t0].[Num], [t0].[Kind], [t0].[QuantityPdo], [t0].[QuantityMadeUnload], [t0].[QuantityCorrect], [t0].[QuantityMadeWorkshop], [t2].[FkProduct] NULL PLAN_ROW 1 1
0 12 |--Bitmap(HASH:([t1].[PkClaimStrAssembly]), DEFINE:([Opt_Bitmap1004])) 1 6 5 Bitmap Bitmap Create HASH:([t1].[PkClaimStrAssembly]) [Opt_Bitmap1004] 1,228427 0 0,02850391 23 8,991221 [t1].[PkClaimStrAssembly], [t2].[FkProduct] NULL PLAN_ROW 1 1
0 12 | |--Parallelism(Distribute Streams, Broadcast Partitioning) 1 7 6 Parallelism Distribute Streams NULL NULL 1,228427 0 0,02850391 23 8,991221 [t1].[PkClaimStrAssembly], [t2].[FkProduct] NULL PLAN_ROW 1 1
0 1 | |--Nested Loops(Inner Join, OUTER REFERENCES:([t2].[PkClaimStr])) 1 8 7 Nested Loops Inner Join OUTER REFERENCES:([t2].[PkClaimStr]) NULL 1,228427 0 5,134826E-06 23 8,962718 [t1].[PkClaimStrAssembly], [t2].[FkProduct] NULL PLAN_ROW 0 1
0 1 | |--Parallelism(Gather Streams) 1 9 8 Parallelism Gather Streams NULL NULL 1,228427 0 0,02850319 23 8,959394 [t1].[PkClaimStrAssembly], [t2].[PkClaimStr] NULL PLAN_ROW 1 1
0 12 | | |--Nested Loops(Inner Join, OUTER REFERENCES:([t1].[FkClaimStr], [Expr1005]) WITH UNORDERED PREFETCH) 1 10 9 Nested Loops Inner Join OUTER REFERENCES:([t1].[FkClaimStr], [Expr1005]) WITH UNORDERED PREFETCH NULL 1,228427 0 1,825085E-05 23 8,93089 [t1].[PkClaimStrAssembly], [t2].[PkClaimStr] NULL PLAN_ROW 1 1
1 12 | | |--Parallelism(Repartition Streams, RoundRobin Partitioning) 1 12 10 Parallelism Repartition Streams NULL NULL 26,19739 0 0,0285139 23 8,952119 [t1].[PkClaimStrAssembly], [t1].[FkClaimStr] NULL PLAN_ROW 1 1
1 12 | | | |--Clustered Index Scan(OBJECT:([Asupr].[dbo].[ClaimStrAssembly].[KeyPkAssembly] AS [t1]), WHERE:([Asupr].[dbo].[ClaimStrAssembly].[FkProduct] as [t1].[FkProduct]=(20967006) AND [Asupr].[dbo].[ClaimStrAssembly].[Quantity] as [t1].[Quantity]>(0.))) 1 13 12 Clustered Index Scan Clustered Index Scan OBJECT:([Asupr].[dbo].[ClaimStrAssembly].[KeyPkAssembly] AS [t1]), WHERE:([Asupr].[dbo].[ClaimStrAssembly].[FkProduct] as [t1].[FkProduct]=(20967006) AND [Asupr].[dbo].[ClaimStrAssembly].[Quantity] as [t1].[Quantity]>(0.)) [t1].[PkClaimStrAssembly], [t1].[FkClaimStr] 26,19739 8,684607 0,1327886 40 8,817395 [t1].[PkClaimStrAssembly], [t1].[FkClaimStr] NULL PLAN_ROW 1 1
0 1 | | |--Index Seek(OBJECT:([Asupr].[dbo].[ClaimStr].[I_ClaimStr_FkClaim] AS [t2]), SEEK:([t2].[FkClaim]=(27331859) AND [t2].[PkClaimStr]=[Asupr].[dbo].[ClaimStrAssembly].[FkClaimStr] as [t1].[FkClaimStr]) ORDERED FORWARD) 1 14 10 Index Seek Index Seek OBJECT:([Asupr].[dbo].[ClaimStr].[I_ClaimStr_FkClaim] AS [t2]), SEEK:([t2].[FkClaim]=(27331859) AND [t2].[PkClaimStr]=[Asupr].[dbo].[ClaimStrAssembly].[FkClaimStr] as [t1].[FkClaimStr]) ORDERED FORWARD [t2].[PkClaimStr] 1 0,003125 0,0001581 15 0,007266807 [t2].[PkClaimStr] NULL PLAN_ROW 1 26,19739
0 0 | |--Clustered Index Seek(OBJECT:([Asupr].[dbo].[ClaimStr].[KeyPkClaimStr] AS [t2]), SEEK:([t2].[PkClaimStr]=[Asupr].[dbo].[ClaimStr].[PkClaimStr] as [t2].[PkClaimStr]) LOOKUP ORDERED FORWARD) 1 16 8 Clustered Index Seek Clustered Index Seek OBJECT:([Asupr].[dbo].[ClaimStr].[KeyPkClaimStr] AS [t2]), SEEK:([t2].[PkClaimStr]=[Asupr].[dbo].[ClaimStr].[PkClaimStr] as [t2].[PkClaimStr]) LOOKUP ORDERED FORWARD [t2].[FkProduct] 1 0,003125 0,0001581 15 0,003319214 [t2].[FkProduct] NULL PLAN_ROW 0 1,228427
0 12 |--Index Seek(OBJECT:([Asupr].[dbo].[WorkshopRoad].[I_WorkshopRoad_FkWorkshop] AS [t0]), SEEK:([t0].[FkWorkshop]=(8)), WHERE:(PROBE([Opt_Bitmap1004],[Asupr].[dbo].[WorkshopRoad].[FkClaimStrAssembly] as [t0].[FkClaimStrAssembly],N'[IN ROW]')) ORDERED FORWARD) 1 18 5 Index Seek Index Seek OBJECT:([Asupr].[dbo].[WorkshopRoad].[I_WorkshopRoad_FkWorkshop] AS [t0]), SEEK:([t0].[FkWorkshop]=(8)), WHERE:(PROBE([Opt_Bitmap1004],[Asupr].[dbo].[WorkshopRoad].[FkClaimStrAssembly] as [t0].[FkClaimStrAssembly],N'[IN ROW]')) ORDERED FORWARD [t0].[PkWorkshopRoad], [t0].[FkWorkshop], [t0].[FkClaimStrAssembly], [t0].[QuantityMade], [t0].[Quantity], [t0].[QuantityReady], [t0].[QuantityDefect], [t0].[QuantityKd], [t0].[Num], [t0].[Kind], [t0].[QuantityPdo], [t0].[QuantityMadeUnload], [t0].[QuantityCorrect], [t0].[QuantityMadeWorkshop] 219063,1 2,382277 0,04018773 117 2,422465 [t0].[PkWorkshopRoad], [t0].[FkWorkshop], [t0].[FkClaimStrAssembly], [t0].[QuantityMade], [t0].[Quantity], [t0].[QuantityReady], [t0].[QuantityDefect], [t0].[QuantityKd], [t0].[Num], [t0].[Kind], [t0].[QuantityPdo], [t0].[QuantityMadeUnload], [t0].[QuantityCorrect], [t0].[QuantityMadeWorkshop] NULL PLAN_ROW 1 1
26 мар 18, 10:40    [21285390]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
nvv
ExB,
Перепишите соединения на вложенные и добавьте условия в соединение.
Исчезнут nested loops и все будет работать мгновенно.


nvv, это предлагается сделать так:
SELECT [t0].*
FROM [dbo].[WorkshopRoad] AS [t0]
INNER JOIN (select t1.[PkClaimStrAssembly] from [dbo].[ClaimStrAssembly] AS [t1] 
INNER JOIN [dbo].[ClaimStr] AS [t2] ON [t2].[PkClaimStr] = [t1].[FkClaimStr]
INNER JOIN [dbo].[Claim] AS [t3] ON [t3].[PkClaim] = [t2].[FkClaim]
WHERE 
	(([t2].[FkProduct] = @p2) OR ([t3].[OtklNumberProduct] = 1)) 
	AND ([t2].[FkClaim] = @p3)
	AND  ([t1].[FkProduct] = @p0) 
	AND ([t1].[Quantity] > @p4)) AS [t1] ON [t1].[PkClaimStrAssembly] = [t0].[FkClaimStrAssembly]
WHERE 
	([t0].[FkWorkshop] = @p1) 


Если да, то не помогло
26 мар 18, 10:43    [21285402]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
ExB
nvv
ExB,
Перепишите соединения на вложенные и добавьте условия в соединение.
Исчезнут nested loops и все будет работать мгновенно.

Если да, то не помогло

Какой смысл что-то переписывать если оптимизатор тупо не видит значений параметров? Правильный ответ уже сказали выше - OPTION(RECOMPILE)
28 мар 18, 00:08    [21291684]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение SQL запроса, количество обработанных записей превышает фактическое  [new]
ExB
Member

Откуда:
Сообщений: 8
Решение OPTION(RECOMPILE)
SELECT [t0].*
FROM [dbo].[WorkshopRoad] AS [t0]
INNER JOIN [dbo].[ClaimStrAssembly] AS [t1] ON [t1].[PkClaimStrAssembly] = [t0].[FkClaimStrAssembly]
INNER JOIN [dbo].[ClaimStr] AS [t2] ON [t2].[PkClaimStr] = [t1].[FkClaimStr]
INNER JOIN [dbo].[Claim] AS [t3] ON [t3].[PkClaim] = [t2].[FkClaim]
WHERE 
	(([t2].[FkProduct] = @p2) OR ([t3].[OtklNumberProduct] = 1)) 
	AND ([t2].[FkClaim] = @p3) 
	AND  ([t1].[FkProduct] = @p0) 
	AND ([t0].[FkWorkshop] = @p1) 
	AND ([t1].[Quantity] > @p4)
OPTION(RECOMPILE)


Всем спасибо!
28 мар 18, 10:57    [21292433]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить