Кто знает: существуют ли ограничения, накладываемые 1С или dbf или SQL, на максимальное количество реквизитов документа?

 

по идее подобных ограничений быть не должно, НО необходимо учитывать тот факт что чем больше реквизитов - тем больше данных (даже если реквизиты визуально не заполнены) и соотвественно это отобразится на скорости чтения/записи ну и размере базы.

 

Кто знает: существуют ли ограничения, накладываемые 1С или dbf или SQL, на максимальное количество реквизитов документа?

У меня в одной из баз есть документ, в котором 117 реквизитов шапки (так исторически сложилось), 8 закладок на форме

 

Если мне не изменяет опять же склероз... В общем в ДБФ есть ограничение на количество колонок... 256 что ли...

 

Если мне не изменяет опять же склероз... В общем в ДБФ есть ограничение на количество колонок... 256 что ли...

Трудно себе представить, что такое количество кому-то реально понадобится. У меня вот вполовину меньше, так и то редактировать их замучаешься - пока вспомнишь, кто есть кто

 

Всем спасибо, впринципе мои предположения подтвердились
Значит ошибку буду искать в другом направлении

 

Hryv, написапл бы прямо что именно тебя тревожит, а то ходишь вокруг да около

 

Я пока сам подробностей не знаю
Сказали, что надо доделать документ, но в нем много реквизитов (и как я уже посмотрел в табл.части есть 10 реквизитов строка длиной 780)
И сказали, что после предыдущей доработки этого документа при перегрузке выдавалась ошибка (какая точно не сказали)
Тогда от ошибки помогло удаление "лишних" реквизитов из документа

Я сразу подумал, что проблема в самой выгрузке/загрузке, но сначала, на всякий случай, решил уточнить есть ли предел по числу реквизитов

 

строка длиной 780

А это что за зверь ?

 

при перегрузке выдавалась ошибка

если перегруз отбирает документы запросом то со строкой 780 символов могут быть проблемы(надо исключить из переменных запроса)

 

В 8-ке, если верить тестам на Профессионала, можно и бошльше 256.

 

Продолжение темы

Вот что выяснилось: речь шла не о перегрузке, а о объединении конфигураций

В тестовой базе на dbf добавил документу 3 реквизита табличной части (число, справочник и документ) - все сохранилось без вопросов
При попытке объединить с базой на SQL выдает сообщение

После уменьшения длины 2-х ранее созданных реквизитов табличной части с 780 до 750 все прошло без вопросов

В принципе, я могу решить проблему уменьшением дляны - но это муторно. В базе десяток или больше доков с этим набором реквизитов и куча функций и процедур заточенных под этот размер, неохота лазить везде и укорачивать

Можно ли как-то решить проблему иначе?

 

ДЕЛО, ПОХОЖЕ, НЕ В КОЛИЧЕСТВЕ РЕКВИЗИТОВ, А В ОБЩЕЙ ДЛИНЕ ОДНОЙ ЗАПИСИ
Может быть, менее болезненно уменьшить длину какого-то малозначительного реквизита (сэкономить-то надо 11 байт вроде)
К тому же, любопытно, зачем было плодить столь длинные строки

 

Я уже понял, что проблема в общей длине, поэтому и укорачивал с 780 до 750

Проблема в том, что я не знаю какие реквизиты там МАЛОзначительные

Строки эти наплодили по дурацки. При торговле мобильниками нельзя просто отгрузить или получить, например, 500 телефонов одной модели, а надо еще IMEI каждого телефона указать. Эти строки для хранения IMEI и предназначены. Я бы делал через справочник, подчиненный партии, но сейчас это уже не исправить.

 

Я бы делал через справочник, подчиненный партии, но сейчас это уже не исправить

ууууууууууууй, сомневаемси...
Мне тут понадобилось в конфигурацию добавить новый регистр... И Накладная на отгрузку должна делать по нему движения. И должны появиться движения по уже проведенным документам.
Хотите сказать, что этого нельзя сделать, без перепроведения документов прошлых периодов?
Невозможно модифицировать структуру данных, если в базе нет самих данных (и при этом отсутствует четкий алгоритм, позволяющий заполнить данные на основании существующих). В остальных случаях Программист может произвести необходимую доработку и модификацию данных.

 

vitfil, я не имел ввиду, что внести эти изменения теоретически невозможно

На данный момент это выглядит абсолютно не рационально по затратам времени: чтобы разобраться во всех хитросплетениях новой для меня базы, переделать и протестировать понадобится дней 10 (а то и больше). Тогда как те изменения, которые нужны по сути - это 3-4 дня работы.

Надо попытаться найти более простое решение