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

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

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

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

заходить с одного компа под одним юзером при живом аналоге 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 полёт нормальный.