Здравствуйте, Алексей!

Специального реестра описаний в базовой версии нет.

Дублирую свой ответ, который был предоставлен Вам в рамках обращения в службу поддержки.

Причины описанной Вами проблемы могут быть самые разные. Для генерации решения нужно определить её источник (база данных, аппаратное обеспечение сервера или клиентские места). В момент возникновения замедлений проверить у всех ли пользователей это происходит одновременно. Если «да», то обратить внимание на сервер, в частности, на загрузку ЦП и оперативной памяти. Если там всё в порядке, тогда нужно моделировать ситуацию и в это время с помощью утилиты «SQL Server Profiler» пробовать отследить проблемные запросы к базе для возможности их оптимизации. Следующий этап – это проанализировать зависит ли замедление от пользователя, админ\не админ (играют ли роль права доступа). На скорость работы (время отклика системы), также, может влиять количество колонок, которые отображаются в реестре записей (желательно лишние спрятать), наличие сортировки по каким-то из полей реестра (убрать сортировку можно зажав Ctrl и кликнув по полю).

Со временем может быть нарушена структура индексов базы данных (создаются для ускорения выборки данных). Их можно перестроить при помощи скрипта Reindex.rar (во вложении). Рекомендации по выполнению скрипта – во вложении. После выполнения скрипта создаётся хранимая процедура «sp_reindex_all_tables». Её нужно запустить на выполнение. В зависимости от количества индексов, размера базы данных и ресурсов сервера выполнение данной процедуры может занять достаточно продолжительное время при этом нагружая сервер. В связи с этим, если вы будете пересоздавать индексы, рекомендую запускать процесс, когда пользователи не работают с системой. Перед этим обязательно создайте резервную копию базы данных.

Если у вас есть проектные решения стоит обратить внимание и на этот момент. Возможно есть нюансы реализации дополнительной логики.

Здравствуйте, Алла!
Спасибо за ответ!
От пользователя не зависит и у админа и у менеджеров база зависает при попытке отобразить описание на конкретных клиентах, причем зависает безвозвратно.
Реиндексацию делали - не помогло, попробуем еще раз.

Появилась идея удалить последнюю запись обновления из Журнала изменений, но не знаем как это сделать.

"Пушкарев Алексей" написал:Реиндексацию делали

Реиндексация для оживления описания это забавный шаг :) поле blob как бы не индексируют, и смысла ускорять реиндексацией его чтение ноль

Просто sql запрос на сервере select * from tbl_Account where Name = 'Как_там_называется_проблемный_клиент' работает?

Если работает - как, время профайлером гляньте, долго-долго?

Сегодня сделали поиск проблемных клиентов с изменениями за последние 3 месяца. все клиенты одного менеджера причем последняя дата изменения у всех после перевода менеджера с Windows 7 на 8 версию. И ошибки лишь на 8 контрагентах, но так как они периодически становятся первыми в общем списке и у всех по умолчанию открыта деталь описание то страдают все.

Наверное пока не стоит связывать переход пользователя с Windows 7 на Windows 8.

Из Вашего сообщения сделал выводы, что на детали [Описание] хранится много информации, где размер поля может превышать более 10 мб. В таком случае рекомендую изменить логику работы приложения, а именно:

• Использовать FILESTREAM
• Использовать таблицы FileTable
• Создать новую деталь, где будет использоваться RTF файл, который размещается на файловой системе