Последние сообщения

#1

Размышлизмы / Re: Личное: Антон Азанов aka D...

Последний ответ от alyuev - Вчера в 19:02

я вот, к сожалению, не зафиксировал как в 1Sqlite включить режим разрешения удаления объектов

https://www.1cpp.ru/forum/YaBB.pl?num=1214205575/988#988

#2

Размышлизмы / Re: Личное: Антон Азанов aka D...

Последний ответ от Злоп - 21 марта 2026, 20:13

Печально. Сильный был программист... Сможет ли кто продложить его дело?

Вряд ли, тем более что большинство что он делал - в обществе 1Сников было известно только мохнатым клюшечникам. А из тех, кто в теме, необходимой компетенцией обладают по моим мутнымощкущениям человека 3 не более.
.
я вот, к сожалению, не зафиксировал как в 1Sqlite включить режим разрешения удаления объектов.   

• [4126]

#3

7.7 / Re: Ручное обновление базы SQL...

Последний ответ от Злоп - 21 марта 2026, 17:52

Ну так и я про это, нужно знать.
Я вообще все потенциально полезное складирую у себя на компе в "репозитарий", интернет - место ненадежное.
Еще бы и этот форум "грабить" регулярно было бы хорошо, каким-нить телепортом. Надеюсь Альф бэкапит его регулярно, и он не поотеряется если интернет/хостинг отвалится или еще что...

#4

7.7 / Re: Ручное обновление базы SQL...

Последний ответ от Ветер в поле - 20 марта 2026, 18:36

Иногда нужно просто знать, что некое решение есть. Например, статью про ручную реструктуризацию справочников я прочитал задолго до реализации данной разработки. И когда понадобилось, вспомнил и воспользовался. Сейчас у меня все скульные базы обновляются по этой системе. Уже более 5 лет. Последние 3 года даже никаких доработок в разработку не требовалось.

#5

7.7 / Re: Ручное обновление базы SQL...

Последний ответ от Злоп - 20 марта 2026, 18:11

Вряд ли пригодиться (в моем окружении клиентов с такими объемами нет, а там где объемы есть - есть свой некрофил-77).
Но на всякий случай сграбил в свой репозитарий.

#6

7.7 / Re: Ручное обновление базы SQL...

Последний ответ от Ветер в поле - 20 марта 2026, 10:41

Публикация готовилась для сайта Инфостарт, но там отказались публиковать. Публиковал эту разработку на форуме 1cpp.ru, но он скорее мертв, чем жив.

#7

7.7 / Ручное обновление базы SQL 7.7

Последний ответ от Ветер в поле - 20 марта 2026, 10:34

Приветствую братьев по некрофилии!
К сожалению, немалое количество программистов до сих пор еще поддерживают нетленки, созданные за пару десятков лет существования платформы 1С: Предприятие 7.7. Но даже крупным и вполне успешным предприятиям переход на более совершенную платформу является весьма непростой задачей. Переписать в сжатое время написанное за предыдущие десятилетия, переобучить сотни-тысячи пользователей вынуждают работать на старом ПО.
Как бы там ни было, но имеются весьма большие базы, которые крутятся на платформе 1С версии 7.7. Естественно, сервером БД выступает MS SQL Server. Обновление баз, имеющих миллионы документов и справочники им не уступающие, превращается в весьма продолжительное мероприятие. В моем случае с проблемой продолжительности обновления,  я столкнулся, когда документов в базе стало в районе трех миллионов штук. Не спасла даже долгая нерабочая ночь с 31 декабря на 1 января. В 9 часов утра мне пришлось прервать обновление конфигурации и вернуться к бэкапу. С учетом того, что сейчас за один только год вводится 4 млн документов, то всякие обрезки базы меня не спасали. Нужно было радикальное, но быстрое решение. И оно было найдено.
Проблема долгой реструктуризации базы данных проистекает из-за крайне неоптимального алгоритма, который применяет фирма 1С. При изменении структуры таблицы, создается новая таблица и туда по тысяче записей за раз переносятся данные. После переноса старая таблица удаляется, а новая получает имя старой. Таким образом, простейшая операция добавления нового поля или банальное увеличение длины строкового реквизита приводит к очень затратной операции. Средний SQL сервер в однопоточном режиме выполняет в районе 1000 операций в секунду. Следовательно, для того чтобы добавить один реквизит в справочник с 10 млн элементов, надо затратить 10 000 секунд – почти 3 часа времени. Немало, но еще не так страшно – ведь вряд ли таких справочников слишком много. Но есть такая операция как пересчет ссылок документов. Это формирование таблицы для отбора документов. Там содержится также информация о подчиненных документах. В общем, эта операция еще медленнее – обрабатывается в районе нескольких десятков документов в секунду. Вот здесь количество документов радикально влияет на скорость реструктуризации базы данных.
Такая засада, на которую фирма 1С обрекла своих пользователей, объясняется просто. Необходимо было минимальными затратами выпустить SQL версию своей платформы. Поэтому 1С использует SQL SERVER в основном как хранилище данных. Грубо говоря, 1С заменила DBF-файлы на таблицы SQL. Это позволило минимально изменять работу с данными по сравнению с DBF. Даже банальные списки документов (журналы) реализованы через курсоры, которые позволяют одному пользователю создать колоссальную нагрузку на современнейший многоядерный процессор. Поэтому во всех журналах документов у меня запрещено просматривать большие массивы информации – некоторые отборы ограничивают период журнала до 3 дней, другие более длительные.
В общем, проблема понятна – надо ее решать. В поисках решения наткнулся на статью Андрея Васильева «Изменение структуры баз 1С 7.7 без долгой реструктуризации. Часть 1. Справочники». Огромное ему за нее спасибо! Эта статья позволила обойти проблему добавления поля с пометкой NOT NULL – было предложено при добавлении поля указывать значение по умолчанию.
Сразу стало ясно, что необходимо автоматизировать процесс формирования скрипта обновления. Скрипт среднего обновления редко бывает меньше 1000 строк и содержит часто более сотни запросов.
Реализация обработки заняла один месяц. Первая версия успешно изменила структуру базы, но 1С вывалилась с ошибкой. Оказалось, что важен порядок следования полей в таблицах! Это, дорогая редакция, полнейшая некомпетентность разработчиков платформы 1С 7.7. Я многое могу понять, но это бред. Еще бы привязались к порядку записей в таблицах. Ну ладно - имеем, что имеем... Пришлось изобретать велосипед. Так как SQL SERVER не имеет команды изменения порядка реквизитов таблицы, то пришлось сначала сохранять во временной таблице данные столбцов, которые мешают нужному порядку, потом удалять их, далее в нужном порядке добавлять реквизиты, а потом восстанавливать сохраненные данные. Во многих случаях я просто пересоздаю таблицу – например, маленькие (меньше 2000 строк) или когда больше 5 столбцов надо сохранять, удалять, добавлять, а потом восстанавливать. В общем, разработка позволила хорошенько развлечься.
Из-за цейтнота не все необходимые реструктуризации были реализованы. Было сделано только то, без чего обновление именно поддерживаемой мной конфигурации будет некорректно. Разработка оплачивалась из расчета потраченного времени на реализацию. Поэтому по достижению результата (обновление конфы) финансирование было прекращено.
Итак, что еще осталось недоделано?
•   Пересчет регистров. Тут больших проблем нет. Добавление реквизитов в любое место абсолютно безболезненно и более никаких манипуляций не требует. Изменения любых реквизитов, кроме измерений тоже безболезненно. А вот удаление, изменение типа реквизитов в измерениях могут приводить к проблемам. Каждый случай тут надо рассматривать отдельно и с полным пониманием как устроен регистр в 1С 7.7. Мои изменения регистров за три года не требовали никаких дополнительных манипуляций. Но я всегда имею данную недоработку в виду и отслеживаю все моменты с ней связанные.
•   Пересчет таблицы ссылок. При добавлении отбора по существующим документам эти документы в отбор не попадут. Также удаление отбора не вызывает удаления связанных с ним данных – т.е. мусор остается в таблице ссылок документов. Изменение типа, кроме банального изменения длины реквизита, тоже приведут к проблемам. Я начал работы по доработке, но прекратил из-за отсутствия финансирования. В своей практике я столкнулся только с проблемой, что добавленный отбор работал только с вновь созданными документами. И это не было критично в том случае.
•   Про бухгалтерские итоги обработка вообще не знает. Она, конечно, изменит структуру полей таблиц, но если изменение структуры требует пересчета бухгалтерских итогов, то это надо делать после обновления вручную средствами самой платформы 7.7. Благо такие изменения редки. Также не забывайте, что изменения в плане счетов могут потребовать пересчета итогов.
•   Не знает обработка и про журнал расчетов. Мне данный механизм абсолютно не был нужен в моих базах. Про ЗиК с удовольствием забыл с появлением ЗУП. Поэтому даже никаких комментариев давать не буду здесь.
•   Не обрабатываются константы. Добавление константы происходит нормально, а больше мне ничего и не нужно было. При удалении константы останется мусор. При некорректном изменении типа (вроде замены строки на справочник) тоже ничего плохого не будет – проставите новое значение и всё. Изменение константы на периодическую скорее всего потребует ручного выставления даты и значения. Особых проблем тут нет – можно не морочиться.
Все эти недоработки можно доделать, но свободного времени как всегда нет. Поэтому из любви к завершенности я доделывать это не планирую. За три года обновления нескольких немаленьких баз (самая большая превысила 260 ГБ, более 15 млн документов) никаких критичных проблем не было. Последняя ошибка при обновлении была более года назад. Поэтому посчитал, что обработку можно опубликовать. При условии ОБЯЗАТЕЛЬНОГО бэкапа перед обновлением, проблем быть не должно.
Теперь о технологии обновления. Предварительно надо создать отдельную базу для обновления. Я ее так и называю – Обновление. Делается она очень просто – создается папка, в которую копируются файлы 1Cv7.MD и 1Cv7.DDS, как минимум (нужны файлы именно рабочей базы!). Также необходимо скопировать все файлы, без которых конфигурация не работоспособна. Т.е. мы создаем копию базы, но без данных. Вообще было бы полезно наполнить эту БД минимальными данными, чтобы можно было тестировать перед обновлением рабочей базы. Но не обязательно. Создаем пустую базу на SQL SERVER и прописываем ее в конфигураторе в качестве БД для нашей конфигурации. Для нее я прописываю модель восстановления Простая, но не принципиально.
Всё, подготовительные действия выполнены. Теперь все обновления должны проходить по следующей схеме.
1.   Делаем обновление базы Обновление через Объединение конфигураций. Также можно вообще вести разработку в данной базе, тогда Объединение конфигураций не нужно.
2.   Тестируем конфигурацию.
3.   Запускаем базу Обновление в режиме 1С:Предприятие, открываем обработку «Ручное обновление базы SQL».

В качестве каталога обновляемой базы выбираем каталог рабочей базы. Изменяем строку подключения к обновляемой БД. Если для вас всё это темный лес, то вы, скорее всего, не готовы к пользованию обработкой. На этом стоит остановиться тогда. Чтобы не вносить постоянно изменения в поля, воспользуйтесь стандартным механизмом сохранения данных формы (вторая пиктограмма слева вверху формы обработки). Корректность строки подключения можно проверить, щелкнув по кнопке «Проверка подключения».
После заполнения полей, можно нажимать на кнопку «Сгенерировать». Это абсолютно безопасно, потому что не вносит никаких изменений – генерируется лишь текстовый файл со скриптами обновления. Рекомендуется изучить текст этого скрипта, чтобы понимать, что будет делать обработка. А делать она будет простые вещи – переведет базу в однопользовательский режим, выполнит по порядку скрипты в текстовом файле, а в конце вернет многопользовательский режим. Сражу скажу, что если вы измените что-то в текстовом файле скрипта, то это ни на что не повлияет.
Самое приятное в данной технологии, что обновление, тестирование и анализ изменений мы делаем в удобное нам время (как правило, рабочее) – не торопясь анализируя необходимые изменения в структуре БД.
Скрипт изменения написан так, что его можно запустить на выполнение вручную в Среде Microsoft SQL SERVER Management Studio. Но это не более, чем опция. Основной режим – выполнение обновления через обработку.
4.   Все тесты и проверки выполнены, пора переходить к обновлению. Прежде всего необходимо, чтобы из программы вышли ВСЕ пользователи. После этого СТРОГО ОБЯЗАТЕЛЬНО надо выполнить полный бэкап обновляемой БД. Иначе если что-то пойдет не так, то вы не сможете вернуть всё как было. Файлы 1Cv7.MD и 1Cv7.DDS особой необходимости бэкапить нет, так как они автоматически сохраняются в папке базы с именами типа 1Cv720220604 053500.md (в имени отражается дата и время бэкапа).
5.   После успешного бэкапа остается только нажать на кнопку «Выполнить обновление». Во время этого процесса происходит следующее:
•   Устанавливается однопользовательский режим БД. Этот этап может сильно затянуться, если кто-то вошел в базу или, возможно, база открыта в Среде Microsoft SQL SERVER Management Studio. Пока не установится однопользовательский режим, процесс продолжен не будет.
•   Последовательно выполняются все скрипты обновления. ЛЮБАЯ ошибка на этом этапе требует восстановления БД из сделанного непосредственно перед обновлением бэкапа. Не искушайте судьбу! Ошибка во время выполнения скриптов – восстановление БД из бэкапа!
•   Переименовываются файлы 1Cv7.MD и 1Cv7.DDS. На их место копируются файлы из базы Обновление. Может получиться так, что в это время кто-то зайдет в 1С и заблокирует эти файлы. Программа обязательно сообщит в табло сообщений о неудаче с копированием файлов. Ничего страшного. Выкидываем заблокировавшего файлы пользователя и ВРУЧНУЮ переименовываем файлы 1Cv7.MD и 1Cv7.DDS. На их место ВРУЧНУЮ копируем файлы из каталога базы Обновление. Будет время и я изменю этот момент и сделаю его более безопасным.
•   Возвращается многопользовательский режим. Можно заходить в режиме 1С:Предприятие.
Все действия во время обновления комментируются в табло сообщений.
Как видите, опасных моментов в процессе ручного обновления немало. Поэтому этот метод следует использовать только если особых вариантов обновить базу нет из-за слишком длительного процесса.
Но если вы обновили базы вышеописанным способом, а потом изменяли конфигурацию рабочей базы традиционным способом, то для возврата к ручному обновлению потребуется привести конфигурацию Обновление к актуальному состоянию. Для этого достаточно зайти в конфигуратор базы Обновление и выполнить «Конфигурация\Загрузить измененную конфигурацию» и сохранить.
Немного о времени на обновление. Если раньше реструктуризация занимала несколько часов (последний раз 8+ и завершения я не дождался), то с помощью моей методики на это уходит от нескольких секунд до десятков минут. Пока самое долгое было 25 минут. Типичное время – в районе 1-2 минут. Размер базы 260+ ГБ.
Для работы обработки необходимы две внешние компоненты – 1cpp.dll и FormEx.dll. Но я думаю, что в базах большого размера эти компоненты применяются по умолчанию. Версии я использую самые последние на данный момент. Думаю, тут проблем быть не должно.
Есть один тонкий момент! Я использую Секретный релиз платформы v77.27.7. Т.е. в качестве сервера SQL мной используется MS SQL SERVER 2008R2 (можно новее). Соответственно и все запросы проверены только для этой связки. С родным сервером могут быть сюрпризы...
Код обработок открыт и более-менее комментирован.

Во вложении обработка и документация (текст поста)

[ТЗ.НОВАЯСТРОКА() - внезапно...]

#8

7.7 / Re: КОПИЛКА: здесь всякие редк...

Последний ответ от Злоп - 20 марта 2026, 02:03

ТЗ.НОВАЯСТРОКА() - внезапно...

ТЗ.НоваяСтрока() - возвращает значение: номер спозиционированной строки, после выполнения метода ТЗ позиционируется на добавленную строку.

ТЗ.НоваяСтрока() - вернет номер последней строки, в этом случае совпадает с количеством строк, т.к добавляется в конец ТЗ.

ТЗ.НоваЯСтрока(N) - вернет номер строки, в данном случае N - т.к. вставляется строка на позицию номер N и позиционируется на нее...

#9

FormEx / Re: Хотелка: АтрибутФормы.Выпо...

Последний ответ от Злоп - 20 марта 2026, 01:58

Так я не ерничаю.

#10

FormEx / Re: Хотелка: АтрибутФормы.Выпо...

Последний ответ от item - 20 марта 2026, 00:59

Возможно, версия 1.0.0.2 тоже работает, но я по совету камрадов заменил 1.0.1.1 на 1.0.0.1.

Обсуждается поломка перехватчика ГК, но 100% это влияет также на контекст в событиях формекс.

Правильную турбу прикрепил.

И да, Злоп, не надо ерничать.
С октября в этой ветке я сам с собой разговариваю.