Здравствуйте, товарищи!
Есть у нас в УПП документ с 42-мя реквизитами.
Добавили мы 43-й реквизит, и примитивный запрос вида
Выбрать * Из Документы.Документ Где Документ.Дата Между Дата1 и Дата2
стал отрабатывать вместо 2-х секунд от 150 до 360 секунд.

Нет ли здесь загвоздки с ограничением количества полей в таблицах SQL Srvr?
Припоминаю, что добавление 4-го субконто в Плане счетов приводило к превышению какого-то допустимого числа полей в таблице (если учитывать, что кроме полей видных в Конфигураторе, в Таблице SQL Srvr добавляется еще N системных полей).
Или, быть может, дело в количестве полей с настройкой "Индексировать" и/или "Полнотекстовый поиск"?
У нового поля нет "Индексировать" но есть "Полнотекстовый поиск".

Заранее благодарю за помощь.

-=up!=-

ДНК?

тип поля?

Все дело в том, а нах...я их 43?

Ну начать надо с того, что отловить непосредственный запрос к серверу. И посмотреть его текст, что в нём. А дальше попытаться его исполнить с анализом плана выполнения

(0) делал справочник с более чем 50 реквизитами...обрабатывал их и объектным методом и запросом - никаких проблем.

(4)Сори... удалите плиз эту пошлость, не сдержался :(
(0)Зачем вам так много полей?

+(0) Какого типа реквизиты?

(2) ну я же не спросил "где ошибка" ;)
(3) ДокументСсылка
(4)(7) дело не в этом, ИМХО. меня беспокоит, что 42 было ОК, а с 43-мя -- завал. А в УПП есть документы и с большим количеством полей, кажется
(5) подскажи как, пожалуйста. быть может, ссылочку?
(8) добавлен реквизит типа "ДокументСсылка". Остальные реквизиты попадаются всякие...

(0) до ограничения вам еще очень далеко. и ограничение, на то и ограничение что не позволит создать больше. а не станет работать медленее.

(10) я опасаюсь, что с достижением числа колонок N таблица каким-то образом разбивается, допустим, на несколько, и время доступа к данным увеличивается

(11) нет. смотрите план работы запроса.

(12) thnx

(9) Тип документ ссылка - если используете что-нибудь в нем через точки - приведет к тому, что будет в скуле join со всеми документами

(14) ойёёй... видимо, в этом и проблема

(14) спасибо!