Здравствуйте! Прошу помочь советом из Вашего опыта:
В конторе несколько разных баз 1С: файловые и серверные на PostgreSQL. Все базы доработаны в разной степени.
Платформу поставил свежую 8.3.15.1830
Исходные конфигурации, которые надо обновлять: БП 3.0.67.43  и ЗУП 3.1.8.216.
Предыдущего админа больше нет и связи с ним нет.
Я ранее работал ТОЛЬКО с файловыми базами. Файловые-доработанные обновил, но со SQL-ми базами вопрос!
Можно ли без потери внешних обработок, которые присутствуют в этих SQL-ых базах сделать обновление следующим образом:
1) Выгрузить SQL_базу_исходник в dt;
2) Обновить в файловом режиме с переносом доработок;
3) Выгрузить Обновленную_Файл_базу в dt;
4) Загрузить dt Обновленной_Файл_базы в SQL_базу_исходник.
Насколько приемлем такой подход и что может нарушиться в работающих SQL-базах?

(0) потроллить решил?

(0) Предыдущего админа больше нет и связи с ним нет. /// <<< Продолжай очень интересно...

Что такое "без потери внешних обработок, которые присутствуют в этих SQL-ых базах"? О чем это?

(0) Процесс обновления конфигурации не зависит от способа организации базы данных. Что в файловой, что в клиент-серверной - одинаково. Единственное, что при работе в клиент-сервере рекомендуется во время обновления конфигурации отключить фоновые задания. А потом - не забыть включить, чтобы выполнились фоновые процедуры обновления.

(1) кого, чего и чем я тролю? Да и на ерунду время не трачу.
(2) умер человек. продолжать?
(3) прочитал, что при переносе SQL-ной базы в файловую через выгрузку в dt можно потерять часть данных. Речь не о том, что файл-база из dt может не загрузиться, а о различных внешних отчетах, обработках и др.
(4) понял, спасибо. А блокировать базу от пользователей надо? Если, подскажите как лучше.

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

(4) А блокировать базу от пользователей надо? Если да - подскажите как лучше. Да и еще, прочитал, что все-таки базы, особенно старые, лучше обновлять в файловом режиме. Почему так - разъяснений не было, но интуитивно согласен, тем более, что личный опыт был только с файловыми.
Спасибо за ответ.

(7) "А блокировать базу от пользователей надо? Если, подскажите как лучше."
А вот это сложно. Сам сталкивался неоднократно с проблемой. Если включить блокировку сеансов в консоли сервера 1с - не получится обновить информационную базу. Если не блокировать - какой-нибудь нетерпеливый пользователь влезет и процесс применения изменений может споткнуться. Штатного способа "чтобы никто не мешал" в 1с нет(

(8) Т.е. в таком случае, т.к. подождать могут, но нетерпеливых достаточно - лучше: выгрузить в dt, включить блокировку сеансов, обновить в файловом варианте, выключить блокировку сеансов, загрузить получившийся после обновлений файловый dt в существующую SQL-базу. Если пойду таким способом, то после загрузки обновленного dt в старую существующую SQL-базу, с этой SQL-базой ничего не должно произойти?

(5) Прочитал и ? А попробовать или база(ы) большие? Бекапов нет?
(6) где ты это все прочитал ? Ссылку скинь ка.

не всякая база выгрузится в dt и загрузится в файловый вариант.

(10) Ранее бэкапы были настроены через выгрузку в dt. SQL-ных бэкапов нет и не было - настрою сам, когда разберусь. Заводить для теста еще одну SQL-базу не буду, т.к. пока не умею.
(10) "где ты это все прочитал ?" - тебя забанили в поисковиках?
(11) да, сейчас делаю тестовую загрузку dt в файловый вариант.

(7) >> базы, особенно старые, лучше обновлять в файловом режиме.

Ересь какая-то.

Не компостируй людям мозг. Обновляй стандартным способом.
Ты не поверишь, но файловая база ничем не отличается от клиент-серверной, кроме того, что используется собственной 1С-овский движок СУБД и та часть функций которые выполняет сервер приложений в файловом варианте ложиться на клиента.

(12) >> тебя забанили в поисковиках?

Ты серьёзно? Ты написал какую-то несусветную *уйню и предлагаешь теперь, чтобы мы искали где ты её вычитал?

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

Разверни себе на тестовые базы, и тестируй все нужные тебе последовательности. Если ты там работник на окладе, то ничего страшного - время уже оплачено.
Если у тебя договор с почасовым расчетом, то будь готов, что времени ухлопаешь гораздо больше, чем будет готов оплачивать Заказчик.

(13) Для него самый стандартный способ - это поднять базу из бакапа где-то в сторонке и тщательно протестить все мыслимое и немыслимое. А уже затем _самому_ сделать выводы о безопасном для Заказчика решении их проблем.

(5)>>>кого, чего и чем я тролю? Да и на ерунду время не трачу.
И сам же пишешь "тебя забанили в поисковиках?".

Чем не троль?

(15) Само обновление необходимо готовить на тестовой базе или базе для разработки. О работе по-взрослому в четырёх изолированных зонах (разработка, предтест, тест, продуктив) автор, по всей видимости, вообще ничего не слышал. Учитывая организацию, когда половина баз на сервере, а половина в файловом варианте, там у заказчика вообще зоопарк и анархия.
На чем эта разработочная база для подготовки обновления будет - всё равно. Хоть файловая, хоть серверная.
А вот тестирование полученного обновления следует делать в том формате, в котором существует база. Если продуктивная база файловая, то тестовая должна быть файловой. Если продуктив клиент-серверный, то и тестирование лучше делать в клиент-серверном, причем на той же версии приложения и СУБД.
Готовое и протестированное обновление переносится в продуктив.

Технология, предлагаемая автором, с выгрузкам/загрузками dt-шников - бред сивой кобылы. Более забористой чуши ещё поискать надо. Для стажа на форуме в 13 лет, кроме как троллингом, такое трудно объяснить.

(13) ты про ересь и *уйню не балаболь, есть по делу - спасибо, остальное оставь себе.
(14) Сервер на Windows Server 2008 Standart, PostgreSQL 9.0.3-3.1С на Win7Проф SP1, выгруженные dt - небольшие, около 1,5ГБ. Загрузку в файловые тестирую.
(15) Да, времени придется ухлопать прилично и конечно "тщательно протестить все мыслимое и немыслимое"
(16) самокритично
(17) Ну не все такие взрослые, как ты. "зоопарк и анархия.." присутствуют, разбираюсь "по-факту". Ты наверно не в курсе, что для стажа нужна только дата регистрации, и не читал, что с SQL-ми базами я ранее не работал. В чем с "выгрузкам/загрузками dt-шников" - бред сивой кобылы?

Хотел написать, что выгружать-загружать в .dt не надо, но вспомнил один случай :)) Однажды попалась серверная база, которая при попытке обновления валилась с не очень информативной ошибкой(не помню какой именно). При этом в файловом варианте обновлялась нормально. Но все оказалось просто - база была немного "битая" и нормально обновилась после ТИИ. При выгрузке - загрузке, как я понимаю, как минимум происходит реструктуризация и реиндексация таблиц. Такое себе ТИИ :))

Меня смущает сочетание PostgreSQL 9.0.3-3.1С(очень старая версия) и платформы 8.3.15.1830(совсем новая), а также версий обновляемых конфигураций(также последних).
Помнится, на PostgreSQL 9.0.3/9.1.2 иногда приходилось именно так и обновлять бухгалтерию или зарплату, как описывает афтор темы, иначе, при обновлении, возникали ошибки. Потом, конечно вендор исправлял ситуацию... Лет 9-10 назад было, еще на 8.2.
Не то чтобы 1С явно не гарантирует работоспособность(без ошибок) новых версий платформы с версиями PostgreSQL десятилетней давности, но и явных гарантий тоже не дает, по крайней я нигде не читал.
Я к тому, что для платформы 8.3.14 и выше, наверное, желательна и последняя версия PostgreSQL, сейчас это 11.5-7.1C, для которой так и пишут - "Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565"

(18) // "выгрузкам/загрузками dt-шников" - бред сивой кобылы?
между моментом выгрузки в дт и моментом загрузки из дт на сервер сколько у тебя времени в запасе есть? Месяц, неделя, день, час или минута? Вот поэтому и пишут, что грузить из дт обновленную базу = бред

(20) Да, видимо тогда все это и было установлено. Последний раз базы обновлялись год или чуть больше назад, номера релизов в файловых и серверных конфигурациях совпадали. Платформу 8.3.15.1830 поставил я на прошлой неделе, т.к. обновленная БП рекомендует/требует эту платформу. После установки пришлось вычистить на сервере1(Win Server 2008 Standart) следы ломалок и старых платформ 8.1/8.2 за прошлые года, т.к. было "Нарушение целостности". Зачем когда-то экспериментировали с ломалками - непонятно, т.к. есть USB-ключики: на 1С-сервер и сетевой на 10 пользователей. Ключ на 1С-сервер был в самом сервере, а сетевой на другом компе в сети. Сетевой перенес на сервер1 и, после танцев с бубнами, "HASP LM" нормально стал раздавать лицензии. С сервером1 действительно бардак, разбор оставлен "на потом", т.к. лучшее - враг хорошего и время жмет.  Пока и серверные необновленные и файловые обновленные работают норм.

(21) Понял, спасибо. Между выгрузкой и загрузкой не месяц, конечно, но срочные начисления и отчеты бухи и зарплатники сдали, ориентировочный срок согласовал - неделю потерпят!
По этому сейчас для меня выходные - самые рабочие.