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