Доброе утро! Вообщем имеется база, достаточно старая и большая, полностью переписанная УТ (там от Ут уже ничего не осталось). Наблюдаются чудеса - периодически пропадает код из конфигурации - вроде вчера еще все работало, а сегодня нет - глядим в конфигуратор - кода нет, смотрим в свои тестовые базы - все на месте. В рабочей базе пытаемся получить обратно из хранилища - ничего не получает как будто изменений нет. Может кто сталкивался? Платформа 8.2 (8.2.15.301), база подключена к хранилищу...

это демоны из отдела демонического обновления шалят

(0) Динамическими обновлениями балуетесь?

ну да, ну да, оно само, я честно вносил..гыыы

(1) опередил, демон )

Как один из вариантов: Убей базу из списка баз (чистка кэша локального) и добавь снова. Эта фигня возникает из за динамического обновления.

Демоническим грешим, каюсь. Но примерно раза 2 в неделю всех выгоняем, сервак перегружаем. А код иногда пропадает месячной давности((((

А по поводу демонического в релизах посвежее проблему исправили?

(6) Кэш чистить не забывайте.

(7) эту проблему официально даже не признавали долгое время. щас хз

(9) А сейчас вообще не рекомендуют.

(8) А кэш то чистить где? На серваке? база на MS SQL

Отключись от хранилища и заного создай его. Такое при динамическом обновлении бывает. Вообще если боевая база подключена к хранилищу, раз в месяц хотя бы убивай его и создавай новое.

боевую подключать к хранилищу вобще является плохим тоном

(0) вы не умеете пользоваться хранилищем
(13) чушь собачья

динамическое обновление тут никаким боком.

90% вероятность проблемы в том, что под одним пользователем ходят в хранилище.

(14) Нет - для каждой базы (1 рабочая и 2 тестовые) для хранилища свой пользователь

(14) >>чушь собачья
нуну.
Столкнёшся с проблемами - поздно будет. Я не про ларьки, а про номральные промышленные базы, никто к хранилищу не подключает их под страхом смертной каздни, так на всех абсолютно крупныех проектах-внедрениях где я был или слышал

(15) у меня есть инструкция без которой я знаю уже две конторы, которые отказывались от хранилища в связи с этой проблемы. изучай приемы работы с хранилищем.

(16) Если правильно использовать хранилище, то вполне нормально его подключать к рабочей. А проблемы возникают у тех, кто не умеет им пользоваться.

А какой глубинный смысл подключения рабочей к хранилищу?

(18) да все умеют пользоваться, и конечно ничего не случится если подключить - я об общепринятой практике говорю, а не о мифических глюках. Эти правила устанавливают крупные внедренцы и Эксперты 1с, а не я

(19) Лень

(19) поставь вопрос наоборот...

(20) "да все умеют пользоваться". Точно так же, как и все "умеют" ключами пользоваться, но почему-то постоянно заводят ветки про неработающие ключи и валят всё на 1С, хотя причина в банальном неумении читать инструкции :)

(21)Как хранилище способствует уменьшению телодвижений?
(22)Какой смысл НЕ подключения?

Хранилище - механизм, облегчающий групповую разработку. Как правило, на рабочей базе разработки не ведутся. Вот мне и интересно: какие такие плюшки еще существуют у хранилища?

(24) Но ведь разработки в итоге должны как-то попадать в рабочую базу? И хранилище для этого самый удобный способ. А те, кто пишет про глюки, просто не умеет его использовать.

(24) разработка ведётся на подключенных базах. хранилище это уже готовая конфигурация, которая не требует лишнее времени для обмена CF-никами между разработчиками. накатывается на рабочей уже модератором с последней проверкой.

(23) я бы не стал обвинять умных людей в неумении пользоваться)
Я нисколько не против хранилища, сам постоянно им пользуюсь, но в базах разработки специальных, никак не рабочих

(24)>>Как хранилище способствует уменьшению телодвижений?

Обновление проходит в два клика мышкой. А иначе надо заводить бодягу с объединением.

(27) Давай тогда пример проблемы с рабочей базой, подключенной к хранилищу. Причём, пример нерешаемой проблемы.

боевую базу к хранилищу подключают только идиоты...

(30) Тебе тоже вопрос (29)

>Обновление проходит в два клика мышкой. А иначе надо заводить бодягу с объединением

откройте для себя поставку... да и в чем "бодяга"? или у вас постоянно меняются роли?

(27)Это дело философии каждого.Держать боевую базу подключенной к хранилищу или нет.
У меня второй год рабочая подключена к хранилищу. Разработку ведем в 4 лица. Пока полет нормальный.

> Давай тогда пример проблемы с рабочей базой, подключенной к хранилищу. Причём, пример нерешаемой проблемы.

мне не нужны проблемы. п.э. я и не подключаю...

проблем с хранилищем документрированых и не очень в 1с было вагон и тележка

любые лишние приблуды в продакшене и на боевых серверах - это зло

(33) Самое смешное, что все кричат про проблемы с рабочей базой, подключенной к хранилищу, но при этом ни один из крикунов не может объяснить, какие же проблемы могут возникнуть. А те проблемы, которые приводят, просто из-за неправильного использования хранилища :)

(29) перечитай (20) внимательней. Не просто так это делается. Вопрос конечно больше филосовский.
В случае сравнения-объединения легче лицезреть все изменения относительно рабочей базы наглядно, человеком накатывающим обновление. Хранилище - черный ящик в этом плане, сравнение конфы с предыдущими версиями - долгий процесс на порядок чем сравнение-объединение

>Если правильно использовать хранилище, то вполне нормально его подключать к рабочей. А проблемы возникают у тех, кто не умеет им пользоваться.

и как им надо "уметь" пользоваться? какие-то сокровенные знания?

(35)Ну тут как везде. Надо просто "уметь их готовить" :-)

(35) С чего ты взял, что не правильно пользуются хранилищем - напиши тогда как правильно, если ты имеешь какоие то сакральные знания

(34) Скажу больше. Принцип бритвы Оккама распространяется не только на программирование -)

(11) НА том компе где открываете базу

(0)У нас тоже были замечены подобные казусы - когда в рабочей базе оказывался код, измененный несколько месяцев назад. Сначала удивлялись, теперь , заметили, меняем :(

(41) Рабочая база с любого компа открывается с пропавшим кодом(

какая нах разница, подключать боевую базу к хоронилищу или нет: всё равно это не спасет от проблем в (0) ИМХО и так гемор с объединением с cf, и с загрузкой изменений из гноилища. + ИМХО в (0) беда с платформой <18-19 релиза

(37) за тысячу баксов я объясню тебе подробно, а так продолжай жить без хранилища )))

(34) т.е. ты не знаешь почему. Просто тебе сказали, что это бяка и ты поверил? :)

P.S. Извиняюсь за набор слов в (44), т.к. в это время сам загружаю изменения из хранилища в боевую ))

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

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

(49) сравни в хранилище 2 его версии, чтоб понять не кто менял, а какой код был и стал после изменений

(49) Зачем эти споры, переубедить не удастся никого, сам пользую хранилище всю дорогу, были проблемы с демоническим, лет 5-6 назад, больше стараюсь не использовать.

(50) Постоянно сравнивал, и что? Мало того, что при этом видно: кто и когда менял, но можно посмотреть ВСЮ историю изменений, т.е. не только что было и что стало после последнего обновления, а можно сравнить с предыдущими изменениями. Причём как всю конфу, так и каждый объект в отдельности.

(52) я не говорю что нельзя, где это вычитал то? я про скорость такого сравнения вглубь версий, это тормоз ещё тот.
Короче не суть, на серъёзных проектах реально не увидишь рабочую промышленную базу в сцепке с хранилищем, это просто факт (если сам не будешь там архитектором), тут спорить не о чем...

Держать рабочую базу, подключенной к хранилищу - плохой тон. Используйте механизм обновлений и поставок.

>Мало того, что при этом видно: кто и когда менял, но можно посмотреть ВСЮ историю изменений, т.е. не только что было и что стало после последнего обновления, а можно сравнить с предыдущими изменениями. Причём как всю конфу, так и каждый объект в отдельности.

да вы чо... ну никто документацию не читал и не в курсе про эти ништяки

(54) Это из разряда: "Пользоваться Касперским - плохой тон"? Чисто религиозный вопрос?

(55) Судя по (50), не все в курсе.

(56) Из практических)) Изучайте внимательно механизм групповой разработки, обновлений и поставки.

И не будет подобных проблем.

(59) Каких проблем? У меня их и так нету. Проблемы у тех, кто не умеет с хранилищем работать. Правда, я так и не понял, какие именно. :)

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

(57) между строк читаешь? знаю я про всё это, и пользуюсь, но не на рабочих базах
(56) считай что религиозный, и люди следующие правилу "не подключать рабочие к хранилищу" просто не умеют им пользоваться, раз тебе так легче. Это подход, стандарт, правило

(43) Просто сделай это. Потом приходи.

(62) Ссылку на этот стандарт и правило можешь дать? И кто его ввёл и почему можешь рассказать?

(60) Проблемы в следующем:
1. При динамическом обновлении, конфигурация может откатиться к предидущей версии.
2. Бывали случаи, когда случайно отключали боевую от хранилища, а при подключении заного, возникали проблемы из-за, того, что последние доработки положенные в хранилище не схватывались.

(65) Первая проблема к хранилищу не имеет отношения, а вторая: "случайно отключали боевую от хранилища" - может возникнуть исключительно из-за кривизны рук. Спасибо за ответ.

(64) какая ссылка? каждый решает сам, это подход конкретных людей с немалым опытом, и их немало.
Лично я сталкивался с несколькими случаями разрушений хранилища. В больших конторах с РИБ например - это абсолютно не приемлимая ситуация.
Если ты не сталкивался с проблемами - не значит что их нет, это как с динамическим - многие уверены что роблем нет, пока не столкнутся в первый раз.

Само назначение инструмента хранилища - групповая разработка, а не обновление баз в 2 клика мышкой. Для обновлений используются другие механизмы для этого предназначенные

(67) РИБ к хранилищу так же не имеет никакого отношения. Разрушение хранилища - опять же кривые руки. Итог: внятного ответа у тебя нет, ни одной причины ты объяснить не можешь, но продолжаешь утверждать, что это якобы "стандарт, правило"? Всё понятно.

Это из разряла: Я случайно отформатировал диск с виндой, ни в коем случае не пользуйтесь виндой :)))

(68) :)
(69) вобще мимо

Короче забей.
Оно работает, ты умеешь им пользоваться. Гуру хранилища, памятник поставить осталось. Остальные все удаки

(69) интересная у тебя манера, по жизни считать своих оппонентов идиотами.

(67) Полностью согласен

(0)А в хранилище-то при этом какая версия? С кодом или без кода?

>Разрушение хранилища - опять же кривые руки

очередной бред

(67) +100500

В семёрке такого не было

(70) Вот тебе ещё одно правило: ни в коем случае не подключай рабочую базу к скулю, т.к. любой идиот с админскими правами может её случайно грохнуть. Повесь в рамку и свято чти.

(71) Я не считаю оппонентов идиотами, когда они могут внятно объяснить мне свои высказывания. Про то, почему нельзя подключать рабочую базу к хранилищу, никто внятно ответить не смог.

(78) в (67) .... сам лично сталкивался с несколькими случаями разрушения хранилища... У меня такое во фране тоже было. У народа тупо падало хранилища. Почему это не считаешь внятным объяснением? Тупо из своего личного опыта? У меня, например, не было никогда проблем с динамическим обновлением, но это не значит, что данной проблемы не существует.

Так же наблюдал такую картину. Рабочая была подключена к хранилищу, с хранилищем работали под разными пользователями. В последнее время слишком часто стали появляться проблемы при обновлении, аналогичные (0). Рабочую базу отключил от хранилища.

(79) Во-первых: Хранилище может разрушиться только при условии подключения к рабочей базе, а иначе не может? И во-вторых: никаких проблем для рабочей разрушение хранилища не несёт.

Извините, что вмешиваюсь, но мне надо спросить.
(78) А как надо работать с хранилищем, чтобы не было проблем и косяков?

(81) очередная отмазка из серии, тут все дурни - один я Д`Артаньян.

(82) ответ будет - следуй инструкции и да пребудет с тобой сила )

(82) Слишком долго объяснять, но например, чтобы не произошло разрушения хранилища, про которое тут пишут, как главный аргумент, если рабочая база подключена к хранилищу, то подтягивать в неё обновления из хранилища надо ВСЕГДА под одним и тем же пользователем и желательно из одного и того же места.

(82)Сделать на каждое подключение отдельного юзера и всегда заходить для каждой отдельной базы только под своим.Уже большинство проблем исчезнет:-)
Самая глючная вещь в хранилище- это зависший сеанс. Раза два пришлось из-за этого пересоздавать

>то подтягивать в неё обновления из хранилища надо ВСЕГДА под одним и тем же пользователем и желательно из одного и того же места.

гы-гы-гы... иначе здравствуй съехавшие id?

"вот п.э. я и не женюсь" (с) о чем говорят мч

и это помимо разрушений, адско тормозной работы в чем-то размером с упп, зависших chekin-ов и прочих прелестей

(85) У меня вопрос демоническим обновлением пользуемся ?

(87) Если всё нормально делать, то и разрушений не будет.

(88) я пользуюсь.

(88) Нет, только в очень исключительных случаях.

еще потенциально опасная операция - переподключение между прочим...

но желающим лишних проблем - подключайте...

(87)Это всего лишь вопрос дисциплины. К тому же пользователь всегда выводится автоматом при входе, только пароль остается ввести. Никаких неудобств.

(92) Компьютер вообще включать опасно. Вдруг что-то разрушится :)

>Если всё нормально делать, то и разрушений не будет.

куда они денутся интересно... файловое гуано со структурой в стиле .1cd - "если что все ппц"

(95) В смысле куда денутся? Их просто не будет :)

вытащить из базы vss можно внешними средствами... если хранилище наипнулось - это надолго

(98) Во-первых, завязывай с матом. а во-вторых - даже если хранилище разрушилось по причине кривых рук - то максимум 10 минут на создание нового и никаких проблем.

Сто?

(85) Ну другого ответа я от тебя и не ожидала....

(101) А что тебя в моём ответе не устраивает? Я ответил на основной вопрос: про разрушение хранилища. А все подобные нюансы разжёвывать, которых достаточно много - извини, даже не собираюсь. Скажу только одно - (93) абсолютно прав: это лишь вопрос дисциплины. Если её нет, то у вас постоянно будет что-то "разрушаться". Но это не причина, чтобы не использовать удобный инструмент.

Разрушение хранилища не относится к проблемам именно самого хранилища - это проблема платформы 1с и её файловых баз вообще. В теории это невозможно, на практике - и тут темы выскакивают. Кому то везёт, кому то нет. Как и с демоническим.

Вопрос подключать к рабочей или нет - вопрос религии. Православные и Католики во многом не согласны, хотя бог у них один.

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

95% что если (0) отвяжет от хранилища и перестанет пользоваться демоническими - проблемы действительно не будет больше (не будем спорить кто виноват из них)

За сим предлагаю прекратить срач и закрыть ветку

>абсолютно прав: это лишь вопрос дисциплины

это "вопрос дисциплины" в силу кривизны "удобного инструмента"

его цель как раз контроль версий и ведение групповой разработки...

заходить с одного компа под одним юзером при живом аналоге vss/svn и прочие шаманства - это адЪ и израиль

У меня хранилище не падало, текущее два года уже стоит. Правда всего четыре разработчика. Административный центр серверный всегда с одного места (один раз новый мальчик пришел и открыл с другой базы, но ничего криминального, кроме потраченного получаса на переподключение, не произошло)

Но я все-таки не вижу выгоды подключать к хранилищу рабочую базу.

Разработка ведется на хранилище, тестирование производится в "центральной" базе, куда сливают все готовые разработки. Т.е. практически в рабочей среде. Рабочая база стоит отдельно и обновляется отдельно. ИМХО, объединением обновлять удобнее. При объединении сложнее накатить изменения случайно - в хранилище всего лишь жмякнуть мышкой на пару пунктов ниже. При объединении можно перенести только часть модуля. Если разработчик перед отпуском забыл отпустить какой-то объект, в "свободной" рабочей базе поправить быстрее.

Да, проблема кривых рук. Но я предпочитаю обезопасить там, где это возможно.

так и что решили?
у самого такая же ситуация была с хранилищем. Пропадают изменения из хранилища (модуль откатывается на одну из предыдущих версий). Причем наблюдается только на одном компе. Т.е. с одного вносятся изменения, переносятся в рабочую, потом если попытаться исправить на втором - то в базу разработки прилетит старая версия.
p.s. При сравнении конфигурации БД базы и хранилища - различия не показываются, но они есть (модули разные).
p.s.s Пользователи точно везде разные (на каждую базу свои).
Помогло пересоздание хранилища, пока полет нормальный.

(106) Вот и мы решили в очередной раз пересоздать хранилище

(107) Если оставите на рабочей базе хранидище - ждите ещё подобных приветов, хотя бы морально подготовьтесь, авось и пронесёт. Обычно людям хватает одного раза. Часть из присутсвующих с ними просто не сталкивалась

(108) "гениальная" часть ))))))

В прошлом году у меня такое бывало. Подумывал что я не правильно обновляю. Или подумал что кто-то балуется. А теперь уже не очень уверен.

(6) И что? В конфигурации демон уже нашалил, создал несколько копий одного и того же объекта. Что-то изменилось - и вместо 1-й копии (актуальной) стала выполняться 2-я (неактуальная).

Стабильная работа подразумевает не только устойчивую работоспособность, но и всестороннюю защиту от дурака aka кривые руки. ИМХО

(112) +100500. Еще один повод держать хранилище немного в сторонке от рабочей базы.

А чо, разрушение хренилища при объединении версий конфигурации уже починили? Или на этот счёт тоже есть волшебная инструкция не пользоваться штатными возможностями?

(108) Часть не сталкивалась, а часть столкнулась и нашли оптимальное решение этих проблем. А так соглашусь с (103) почти полностью, но повторюсь: если не получается работать с хранилищем, либо лень искать методы решения проблем, то наверное не стоит с ним иметь дела вовсе. Хранилище вещь хрупкая и требует достаточно бережного обращения.

(85) Не назовешь страницу руководства, где об этом написано?

(102) Это не вопрос дисциплины. Это глючность программы. И да, люди не идеальны. И на старуху бывает проруха...

(108) >>Если оставите на рабочей базе хранидище
см (106) - причем здесь рабочая?
точно также можно и на базе для разработки потерять изменения.

(116) Это внутреннее руководство, которое было разработано при исследовании проблем, возникающих с хранилищем на практике.

(117) Согласен. Люди не идеальны. Но одни при возникновении проблем кричат: "ваша программа не работает", и перестают её пользоваться, а другие анализируют причины возникновения проблем, ищут методы решения, и находят их.

(119) В топку внутреннее руководство. Все должно быть описано в штатной документации, либо это банальные глюки, а ваше внутреннее руководство - это лишь сборник workaround'ов. Которые, между прочим, были выявлены в результате набития шишек на глюках. Hint: при смене версии появляются новые глюки, так что не зарекайся.

(120) Это не отменяет того факта, что хранилище - глючная поделка. И уже только из-за этого не должно использоваться в среде, находящейся в промышленной эксплуатации.

(121) Да. Согласен. Все руководства надо выкинуть в топку. Всё надо всегда делать методом тыка, причём одну и ту же проблему надо решать каждый раз по новой. К чему иметь описание решения проблемы, ведь любая программа по определению глючная :)

кэш у себя чистим, кэш хранилища чистим тоже (там папочка тоже есть специальная cache называется)

(118) да я автору говорил. Всё можно потерять, и не только из хранилища... базы бывают падают, уборщицы о провода затыкаются... Для рабочей базы эти последствия более неприятны просто, для баз разработки - сделал новое хранилище и дальше понеслась

> Хранилище вещь хрупкая и требует достаточно бережного обращения.

потому что написано рукож.пыми людьми... за практику работы с vss например не сталкивался ни разу с разрушением базы и необходимостью некого внутреннего регламента по работе с ним - "не держите его так"

1с кстати разу вместо выгрузки структур в файлы и интеграции с готовыми решениями типа vss/svn нагородила костылей

(126) с тем количеством файлов которое генерит конфа - svn нервно курит в сторонке.

(126) Напиши лучше. И не пользуйся 1С. Никто же тебя не заставляет.

(125) Кстати, глюк, как в (0), наблюдался при динамическом обновлении на базах, которые никогда не были подключены к хранилищу. Отсюда вывод: хранилище, скорее всего, тут ни при чём.

(128)
- Хранилище глючит!
- Нет, не глючит! Это у вас руки кривые!
- Нет, глючит! (пример), (пример), (пример).
- Ну и работай тогда в блокноте, если не нравится...
__
Как-то по-детски это -)

(129) типа у любого глюка может быть только одна причина?

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

(123) Зачем добавлять в промышленно эксплуатируюемую ИС абсолютно ненужный функционал с абсолютно ненужными глюками?

голосовалку надо добавить:
1. Боевая подключена в хранилище
2. Нечего боевой делать в хранилище

Мой ответ 2. ))))

(115)
Разрабатывать же на рабочих базах - моветон, и с этим согласятся все.  - верно.
у нас для такого случая используется одно хранилище, и к нему подключены 2 базы: одна рабочая, одна для разработок и тестов. клиент конечно не очень большой, но и не ларек. как говорится полет нормальный.

(135) ответ к (103)

(133) Затем, что этот функционал предназначен для удобства групповой разработки. Можно, конечно, не подключать рабочую к хранилищу и накатывать обновления через поставку, но зачем эти костыли, когда можно прекрасно делать это напрямую?

(135) А я где-то говорил про разработку на рабочей базе? Не припомню такого.

(137) можно нормально обновляться и без поставок

(135) Некоторые бэкапов вообще не делают, и уже лет 20 как не делают. Считают, что незачем, ведь ни разу не пригодился...

(137) :) Прекрасно? Прекрасно будет когда вашу внутреннюю инструкцию вы выкинете в топку. Проще гораздо сделать сравнение и объединение, чем ходить по минному полю постоянно рискуя.

Удобство хранилища нивелируется его глюками.
Глюки хранилища нивелируются его удобством.

Каждый выбирает для себя что душе приятней.

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

(140) сделай сравнение и объединение это автоматически, хотелось бы посмотреть на это...

(140) Ты теоретизируешь, а я говорю на основании опыта, т.к. мы все проблемы с хранилищем решили.

(142) >обычно "чик-чик и в продакшин", ща бухгалтерия потестит

http://www.xiper.net/assets/images/uncensored/how-made-sites.jpg

Ну Я разрабатываю на рабочей.
Так-что по-мелочи если. И что?
\

(126) Поддержу про золопоруких программистов. Очень удивило когда при сравнение конфы хранилища и БД не показывало разницу. Сделал вывод, что сравнивались по версиям объектов. (133) (141) Народ, а какие глюки? Я вроде вот внимательно ветку почитал и кроме (0) только увидел "вот у вас еще и не ТАКОЕ будет"...

(142) А зачем автоматически? Все равно контролировать изменения надо перед внесением в боевую.

(139) когда cf загружаешь, откуда ты знаешь что это правильный cf файл? Хранилище хоть со своими уродскими диалогами встанет на пути в случаи ошибки.

(143) Это ты думаешь, что все проблемы решили.

>когда cf загружаешь, откуда ты знаешь что это правильный cf файл?

ну вообще я понимаю что я делаю...

(146) К сожалению, глюки 1С не заканчиваются на хранилище. Что ты предлагаешь? Не использовать 1С? Это вариант. Другой вариант - это систематизация этих глюков и поиск решения работы для того, чтобы их не возникало. Ты какой выберешь?

(149) Я это знаю, т.к. их больше не возникает :)

(147) Зачем?  У меня проходят тесты, регресионные тесты, тестирование, анализ времени на реструктуризацию, скоро будет покрытие нового кода тестами и принимается решение об обновлении, зачем мне контролировать самый последний и ненужный этап?

(150) а если стажер не тот cf подсунет? Рука дрогнула и не ту версию выбрал?

(154) Тогда мы увидим тему "Помогите восстановить базу" :)

(154) бэкап перед любым обновлением очень сильно облегчает жизнь.

(154) куда он его подсунет? у него доступа к боевой базе нет и  быть не может по определению

(155) что-ты, такие люди никогда не забывают вручную сделать бэкап, они не доверяют компьютеру и какому нибудь скрипту. Сами каждый раз делают бэкапы и т.д.

(157) не притворяйся, у тебя cf как названы ? 1cv8.cf или 1cv8_latest.cf или 1cv8_ver98.cf ?

(148) По изменениям в результате сравнения.

(152) ПОКА не возникает.

(153) Чтобы быть уверенным, что боевая база ИСПРАВНА и находится именно в том состоянии, которое требуется.

(154) У тебя стажер боевую базу обновляет?

(151) второй вариант выглядит конечно предпочтительнее. Вопрос только в том, сколько еще народу надо держать для выполнения данной работы?

Спёрли код, гады! )))

(159) какая разница как они называются... я знаю что я делаю. всегда

(160) стажер нет, а cf можно спутать запросто.
Ответь лучше на (153) .


(163) когда пьян?

(161) В смысле сколько? Отдельных людей для этого не требуется, т.к. не работая, а только тестируя, ты с большей частью глюков скорее всего не столкнёшься. Да, конечно, на анализ разных глюков и разработку методов их обхода или решения уходит какое-то время. Зато в дальнейшем позволяет безбоязненно и с полным пониманием использовать все удобства программы, что опять же сокращает время на разработки.

>стажер нет, а cf можно спутать запросто

нельзя иначе метлу в руки...

(164) 1. cf даже если и попутаешь - то по характеру изменений будет ясно, что не тот.
2. В (160) ответ уже есть.

(165) причем тут ... только тестируя.... если речь идет о глюках программы при ее использовании вообще?

(166) т.е. у вас существует некий внутренний регламент по обновлению базы, иначе кирдык? Тогда к чему был сарказм по поводу хранилища? С ним всё точно так же :)

(167) он обновление походу делает загрузкой файла. Там фиг чего увидишь.

(168) Каждый глюк имеет решение либо метод обхода. Было бы желание работать в дальнейшем без него.

(166) (167) ладно потролили друг друга и хватит. Каждый для себя выбирает свою систему дэплоя.

(0) такая же штука была. хз почему, но в рабочей базе не было двух строк кода. Не стал заморачиваться, просто добавил в код пробел и поместил в хранилище

>у вас существует некий внутренний регламент по обновлению базы

нет у нас ничего. просто есть понимание что можно делать а что нет. на основании штатной документации

(171) ну про метод обхода - это понятно. Временные то затычки никто не отменял, пока 1С не нашла решения. Ибо заниматься систематизацией ее ошибок и т.п. мне и в голову не придет. Потому как есть работа. А вот что такое - глюк имеет решение?

(174) А с хранилищем такого понимания нет? Вот поэтому вы его и не используете оптимально :)

(176) походу этой ветки понятие работы с хранилищем есть всего у пары человек. Ты бы уж простил простых смертных то?

(175) Например: есть глюки, которые возникают исключительно по причине некорректных настроек винды/сети/прав и т.п. Они имеют решение, хотя не всегда их описание найдёшь в официальной документации.

(0) версии платформы у клиентов и хранилища отличаются?

(178) угу - ты сюда еще глюки возникающие при употреблении грибов приплети.

(181) + 1000

я все жду когда еще сокровенным поделится... чесночная клизьма перед первым входом в хранилище... или правильное жертвоприношение при chdbfl.exe над хранилищем

нуну, не надо уж, по п.8 загремите, и никому от этого лучше не станет

(185) не в первой. Да и поработать надо ) А то после больницы все никак в рабочий ритм не войти.

(182) "мат" выкинь и пости, эмоционально, но красиво сказал)

(184) меня больше интересует описание процесса данных исследований.

(187) под эмоционально, он походу имел ввиду - больше смайликов.

(185) да тут обсуждать то что... кто хотел тот сказал, кто читал тот понял

кто-то унесет тайну безглючной работы с хранилищем с собой в могилу - да и хрен с ней... в 1с глюков хватает чтобы не присовокуплять к ним еще проблемы с хранилищем в продакшене

(190) Вот этим и отличаются два типа программистов: одни ищут методы решения проблем и находят их, а другим "думать некогда, им работать надо". Только вот качество их работы, как правило, соответствует их подходу. Все свои косяки они тупо списывают на глюки 1С :)

(191) не всё зависит от программистов, ошибки платформы никто же не отменял. гарантии что не навернётся никто не даст, а посему намного спокойней держать хранилку подальше от рабочей.
Как пожет быть это мой косяк при разрушении хранилища? С утра подключаюсь - он не алё, реанимация не проходит никак, файло повереждено

(191) успехов в поиске методов решения проблем работы платформы 1С. К внутренностям которой ты вообще доступа не имеешь и все решать можешь только методом тыка - так сделал - о работает, а так нет. Запишем, ну и т.д..

(192) Согласен, не всё. Но большинство глюков вполне поддаются анализу и решению. Остальные исправляет уже сама 1С, выпуская новые релизы, и при этом внося новые. Так что этот процесс бесконечен. Но опять же, я так и не понял, чем же грозит разрушение хранилища рабочей базе? У нас, пока мы не разобрались с работой хранилища, оно разрушалось периодически. Лечилось банальным созданием нового. На работе базы это никоим образом не сказывалось.

(194) я почти всегда работал в базах РИБ, тут очевидно - переподключение к хранилищу = заливка новой конфы = едет она во все узлы с обменами. Это частный случай, но он имеет место быть

(195) Какое переподключение? Если у тебя разрушилось хранилище, то создаёшь новое из рабочей и никакой заливки новой конфы не происходит.

(126) Вы vss к 1С подключили или чисто для сравнения?

У меня были проблемы с необновлением из хранилища, лечил пересозданием (с сожалением теряя историю). Кстати, как любитель динамического обновления, заметил, что проблемы сравнения после него лечились Проверкой/Тестированием с реструктуризацией.

(6) Месячные

>> Платформа 8.2 (8.2.15.301)

Зачем такое старьё использовать? Там кучу ошибок исправили в следующих версиях (и новые внесли, да). 8.2.19.68 полёт нормальный.