Привет всем!
Как стали разбираться почему медленно идёт сохранение документов оказалось что СУБД делает сканнирование всей таблицы даже когда получает даже как условие точное значения ПК. Только запрос в таком случае формируется и передаётся в виде
"Update DocumentItem Set PunktDocument = ? Where ID_DocumentItem = ?" и тдельно параметры
в MonSysSqlText текст видно как
Update DocumentItem Set PunktDocument = @0001 Where ID_DocumentItem = @0002
если пишу прямо Update DocumentItem Set PunktDocument = 5 Where ID_DocumentItem = 988457 то ПК использует
Мне известно что сканикрование таблицы происходит при передаче параметра с несоотвествующим типом может с этим как-то связано?

"...........Я не понял, в чем разница в двух выполняемых запросах......."

Разницы в них в действительности нет, а есть разница в только способе его передачи.

".....В любом случае нужно посмотреть на точный текст запросов , если они в процедуре или триггере - на весь текст процедуры или триггера............"

'Update DocumentItem Set PunktDocument = ? Where ID_DocumentItem = ?'
единственный простейший запрос который передаётся отдельно программой правда в транзакции вместе с другими разными и такими же.

Извиняюсь за то что толком не объяснил в начале. Как мне обяснили сотрудники они текст запроса могут передавать отдельно от параметров тоесть они где-то у себя пишут (дословно) 'Update DocumentItem Set PunktDocument = ? Where ID_DocumentItem = ?', и отдельно передают значения параметров и типы (.Net имеет поддерживает такую возможность и так им немоного легче т.к. небеспокоятся например о преобразовании в текст дат и т.п.) ,очевидно также информация (по-отдельности) передаётся через ODBC на сервер.
Больше объяснить не могу т.к. сам не пишу програм и рассказываю то что мне рассказали .
Потом как мы заметили что план запроса нетот, сделали так, что именно в условии where для ПК не стоит '?' а конкретное значение и теперь работает нормально. Хотя известно покрайней мере что когда-то старый вариант тоже нормально работал (потому что когда-то в этом же месте теже были проблемы с планом . Тогда я сделал то-ли update index statistics толи reorg rebuild и оно стало нормально опять работать, теперь же это не помогло и сделали то что и я сказал). Почему поламалось не знаем единственное что делал за последние дни это действительно добавил достаточно много индексов в базу (но не для этой таблицы!).
Дополню, что как минимум таких таблиц сразу заметили 6. Их могло быть и в 8 раз больше но разбираться мы не стали и сразу поменяли всё. Теперь просто мне интересна причина. Очевидно есть разница в том как смотрит сервер на запрос в этих двух случаях и я думал может кто-то сможет подсказать.

Спасибо за вразумительный ответ. Удачи!