Кто знает: существуют ли ограничения, накладываемые 1С или dbf или SQL, на максимальное количество реквизитов документа?
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
- Статус
по идее подобных ограничений быть не должно, НО необходимо учитывать тот факт что чем больше реквизитов - тем больше данных (даже если реквизиты визуально не заполнены) и соотвественно это отобразится на скорости чтения/записи ну и размере базы.
У меня в одной из баз есть документ, в котором 117 реквизитов шапки (так исторически сложилось), 8 закладок на форме
Если мне не изменяет опять же склероз... В общем в ДБФ есть ограничение на количество колонок... 256 что ли...
Трудно себе представить, что такое количество кому-то реально понадобится. У меня вот вполовину меньше, так и то редактировать их замучаешься - пока вспомнишь, кто есть кто
Всем спасибо, впринципе мои предположения подтвердились
Значит ошибку буду искать в другом направлении
Значит ошибку буду искать в другом направлении
Я пока сам подробностей не знаю
Сказали, что надо доделать документ, но в нем много реквизитов (и как я уже посмотрел в табл.части есть 10 реквизитов строка длиной 780)
И сказали, что после предыдущей доработки этого документа при перегрузке выдавалась ошибка (какая точно не сказали)
Тогда от ошибки помогло удаление "лишних" реквизитов из документа
Я сразу подумал, что проблема в самой выгрузке/загрузке, но сначала, на всякий случай, решил уточнить есть ли предел по числу реквизитов
Сказали, что надо доделать документ, но в нем много реквизитов (и как я уже посмотрел в табл.части есть 10 реквизитов строка длиной 780)
И сказали, что после предыдущей доработки этого документа при перегрузке выдавалась ошибка (какая точно не сказали)
Тогда от ошибки помогло удаление "лишних" реквизитов из документа
Я сразу подумал, что проблема в самой выгрузке/загрузке, но сначала, на всякий случай, решил уточнить есть ли предел по числу реквизитов
если перегруз отбирает документы запросом то со строкой 780 символов могут быть проблемы(надо исключить из переменных запроса)
Продолжение темы
Вот что выяснилось: речь шла не о перегрузке, а о объединении конфигураций
В тестовой базе на dbf добавил документу 3 реквизита табличной части (число, справочник и документ) - все сохранилось без вопросов
При попытке объединить с базой на SQL выдает сообщение
После уменьшения длины 2-х ранее созданных реквизитов табличной части с 780 до 750 все прошло без вопросов
В принципе, я могу решить проблему уменьшением дляны - но это муторно. В базе десяток или больше доков с этим набором реквизитов и куча функций и процедур заточенных под этот размер, неохота лазить везде и укорачивать
Можно ли как-то решить проблему иначе?
Вот что выяснилось: речь шла не о перегрузке, а о объединении конфигураций
В тестовой базе на dbf добавил документу 3 реквизита табличной части (число, справочник и документ) - все сохранилось без вопросов
При попытке объединить с базой на SQL выдает сообщение
После уменьшения длины 2-х ранее созданных реквизитов табличной части с 780 до 750 все прошло без вопросов
В принципе, я могу решить проблему уменьшением дляны - но это муторно. В базе десяток или больше доков с этим набором реквизитов и куча функций и процедур заточенных под этот размер, неохота лазить везде и укорачивать
Можно ли как-то решить проблему иначе?
Вложения
ДЕЛО, ПОХОЖЕ, НЕ В КОЛИЧЕСТВЕ РЕКВИЗИТОВ, А В ОБЩЕЙ ДЛИНЕ ОДНОЙ ЗАПИСИ
Может быть, менее болезненно уменьшить длину какого-то малозначительного реквизита (сэкономить-то надо 11 байт вроде)
К тому же, любопытно, зачем было плодить столь длинные строки
Может быть, менее болезненно уменьшить длину какого-то малозначительного реквизита (сэкономить-то надо 11 байт вроде)
К тому же, любопытно, зачем было плодить столь длинные строки
Я уже понял, что проблема в общей длине, поэтому и укорачивал с 780 до 750
Проблема в том, что я не знаю какие реквизиты там МАЛОзначительные
Строки эти наплодили по дурацки. При торговле мобильниками нельзя просто отгрузить или получить, например, 500 телефонов одной модели, а надо еще IMEI каждого телефона указать. Эти строки для хранения IMEI и предназначены. Я бы делал через справочник, подчиненный партии, но сейчас это уже не исправить.
Проблема в том, что я не знаю какие реквизиты там МАЛОзначительные
Строки эти наплодили по дурацки. При торговле мобильниками нельзя просто отгрузить или получить, например, 500 телефонов одной модели, а надо еще IMEI каждого телефона указать. Эти строки для хранения IMEI и предназначены. Я бы делал через справочник, подчиненный партии, но сейчас это уже не исправить.
ууууууууууууй, сомневаемси...
Мне тут понадобилось в конфигурацию добавить новый регистр... И Накладная на отгрузку должна делать по нему движения. И должны появиться движения по уже проведенным документам.
Хотите сказать, что этого нельзя сделать, без перепроведения документов прошлых периодов?
Невозможно модифицировать структуру данных, если в базе нет самих данных (и при этом отсутствует четкий алгоритм, позволяющий заполнить данные на основании существующих). В остальных случаях Программист может произвести необходимую доработку и модификацию данных.
vitfil, я не имел ввиду, что внести эти изменения теоретически невозможно
На данный момент это выглядит абсолютно не рационально по затратам времени: чтобы разобраться во всех хитросплетениях новой для меня базы, переделать и протестировать понадобится дней 10 (а то и больше). Тогда как те изменения, которые нужны по сути - это 3-4 дня работы.
Надо попытаться найти более простое решение
На данный момент это выглядит абсолютно не рационально по затратам времени: чтобы разобраться во всех хитросплетениях новой для меня базы, переделать и протестировать понадобится дней 10 (а то и больше). Тогда как те изменения, которые нужны по сути - это 3-4 дня работы.
Надо попытаться найти более простое решение
- Статус
Обучение наступательной кибербезопасности в игровой форме. Начать игру!