Максимальное количество реквизитов документа

  • Автор темы Hryv
  • Дата начала
Статус
Закрыто для дальнейших ответов.
H

Hryv

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

KiR

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

vbs

Well-known member
18.02.2007
1 708
1
#3
Кто знает: существуют ли ограничения, накладываемые 1С или dbf или SQL, на максимальное количество реквизитов документа?
У меня в одной из баз есть документ, в котором 117 реквизитов шапки (так исторически сложилось), 8 закладок на форме :unsure:
 

vitfil

IT-интегратор
02.04.2004
2 062
0
#4
Если мне не изменяет опять же склероз... В общем в ДБФ есть ограничение на количество колонок... 256 что ли...
 

vbs

Well-known member
18.02.2007
1 708
1
#5
Если мне не изменяет опять же склероз... В общем в ДБФ есть ограничение на количество колонок... 256 что ли...
Трудно себе представить, что такое количество кому-то реально понадобится. У меня вот вполовину меньше, так и то редактировать их замучаешься - пока вспомнишь, кто есть кто
 
H

Hryv

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

KiR

НЕ шибка опытный програмер)
11.09.2007
1 581
0
#7
Hryv, написапл бы прямо что именно тебя тревожит, а то ходишь вокруг да около
 
H

Hryv

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

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

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

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

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

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

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

Вложения

vbs

Well-known member
18.02.2007
1 708
1
#13
ДЕЛО, ПОХОЖЕ, НЕ В КОЛИЧЕСТВЕ РЕКВИЗИТОВ, А В ОБЩЕЙ ДЛИНЕ ОДНОЙ ЗАПИСИ
Может быть, менее болезненно уменьшить длину какого-то малозначительного реквизита (сэкономить-то надо 11 байт вроде)
К тому же, любопытно, зачем было плодить столь длинные строки
 
H
#14
Я уже понял, что проблема в общей длине, поэтому и укорачивал с 780 до 750

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

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

vitfil

IT-интегратор
02.04.2004
2 062
0
#15
Я бы делал через справочник, подчиненный партии, но сейчас это уже не исправить
ууууууууууууй, сомневаемси...
Мне тут понадобилось в конфигурацию добавить новый регистр... И Накладная на отгрузку должна делать по нему движения. И должны появиться движения по уже проведенным документам.
Хотите сказать, что этого нельзя сделать, без перепроведения документов прошлых периодов?
Невозможно модифицировать структуру данных, если в базе нет самих данных (и при этом отсутствует четкий алгоритм, позволяющий заполнить данные на основании существующих). В остальных случаях Программист может произвести необходимую доработку и модификацию данных.
 
H
#16
vitfil, я не имел ввиду, что внести эти изменения теоретически невозможно

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

Надо попытаться найти более простое решение
 
Статус
Закрыто для дальнейших ответов.