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

Тема в разделе "1C и всё что с ней связано", создана пользователем Hryv, 3 сен 2009.

Статус темы:
Закрыта.
  1. Hryv

    Hryv Гость

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

    KiR НЕ шибка опытный програмер)
    1C Team

    Регистрация:
    11 сен 2007
    Сообщения:
    1.581
    Симпатии:
    0
    по идее подобных ограничений быть не должно, НО необходимо учитывать тот факт что чем больше реквизитов - тем больше данных (даже если реквизиты визуально не заполнены) и соотвественно это отобразится на скорости чтения/записи ну и размере базы.
     
  3. vbs

    vbs Well-Known Member

    Регистрация:
    18 фев 2007
    Сообщения:
    1.708
    Симпатии:
    3
    У меня в одной из баз есть документ, в котором 117 реквизитов шапки (так исторически сложилось), 8 закладок на форме :unsure:
     
  4. vitfil

    vitfil IT-интегратор

    Регистрация:
    2 апр 2004
    Сообщения:
    2.070
    Симпатии:
    0
    Если мне не изменяет опять же склероз... В общем в ДБФ есть ограничение на количество колонок... 256 что ли...
     
  5. vbs

    vbs Well-Known Member

    Регистрация:
    18 фев 2007
    Сообщения:
    1.708
    Симпатии:
    3
    Трудно себе представить, что такое количество кому-то реально понадобится. У меня вот вполовину меньше, так и то редактировать их замучаешься - пока вспомнишь, кто есть кто
     
  6. Hryv

    Hryv Гость

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

    KiR НЕ шибка опытный програмер)
    1C Team

    Регистрация:
    11 сен 2007
    Сообщения:
    1.581
    Симпатии:
    0
    Hryv, написапл бы прямо что именно тебя тревожит, а то ходишь вокруг да около
     
  8. Hryv

    Hryv Гость

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

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

    vbs Well-Known Member

    Регистрация:
    18 фев 2007
    Сообщения:
    1.708
    Симпатии:
    3
    А это что за зверь ?
     
  10. kaa

    kaa Гость

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

    unknown181538 НеГуру
    1C Team

    Регистрация:
    28 дек 2008
    Сообщения:
    1.418
    Симпатии:
    0
    В 8-ке, если верить тестам на Профессионала, можно и бошльше 256.
     
  12. Hryv

    Hryv Гость

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

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

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

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

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

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

    Вложения:

    • message.JPG
      message.JPG
      Размер файла:
      20,1 КБ
      Просмотров:
      18
  13. vbs

    vbs Well-Known Member

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

    Hryv Гость

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

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

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

    vitfil IT-интегратор

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

    Hryv Гость

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

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

    Надо попытаться найти более простое решение
     
Загрузка...
Статус темы:
Закрыта.

Поделиться этой страницей