Меня круто заклинило, причем 2 раза :((((
Я вообще не знаю, что делать :((
Я обновила бюджетную бухгалтерию на типовую
данные не потерялись, но я не знаю как теперь вернуть все обратно. Сохраненных данных нет.
Я знаю, что я полная дура, поэтому не надо высказывать свои мысли по этому поводу. Просто если можно что-то сделать, то скажить, что мне делать.

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

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

Обратным порядком - весьма сомнительно.

Однозначно.
Многие реквизиты справочников, доков.
Просто напросто удаляются.
А значит улетают и их значения.

Так здесь и идет речь о том что спасти то что осталось.
Дааа, самое страшное что у меня было это обновление базовой упрощенки на проф. Архив для меня святое.

(5) Прикинь что осталось.
Если бюдж.план счетов объединить с хозрасчетным, к примеру...
Много ли аналитик?

Арктический зверек базе.... Подкрался ...

Впрочем, если после обновления базы не было открытия доков .... а ..... о чем это я ....

НЕТ КОПИИ - ОБРАТНОЕ ОБЪЕДИНЕНИЕ невозможно.... Не с чем объединять ...

Прощай.... база... ты была красивой ....

Получилось два плана счетов,
Сохранились значения всех справочников, сохранились документы, и их проводки.
Нарушена уникальность кодов в спр.Контрагенты, и кодов Услуги сторонних организаций, и пропали счета в документах, и соответственно аналитика.

Бэкапа нету что ли?

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

Да похоже Пит прав

(9) А причем тут Борис...ты от куда рухнул

(11) Ну или любой другой разработчик ядра 1С (я правильно понял - или адресом ошибся?

Борис не является разработчиком ядра...

Слушай Ромикс, ты это, фильтруй речь.... культурнее надо быть

(14) я имел в виду разработчиков ядра - что они делают умное лицо когда у (0) падает база. В нормальных системах бэкап идет автоматом.

(9) А кто сказал, что 1С копии не сохраняет?

+(16) В папке ./NEW_STRU

(9) Запомни.... 1С нак ласть на тебя .... Она считает, что это не ее проблемы.....

Исходя из этого планируй все свои действия........

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

(17)Гы-гы-гы...
И много ты там данных найдешь?

(16) Сохраняет в New_stru только копию MD
Тане в (0) это разве поможет?

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

Вообще говоря... если базу не лапали после обновления .... можно много вытянуть ... почти все ...

(0) Есть хоть один документ, который не изменился (структура именно)? Если нет, то тогда вообще все данные сохраниться в New_stru

(24) ковыряться надо будет - мама, не горюй....

послушайте, вы ей лучше подскажите что можно попробовать сделать. насколько я понимаю первое это сохранить то что осталось, т.е. сделать копию. Дальше (327) объясни если можно, потому что это интересно.
и ей что делать: нести к спецам из франчей, или выкидывать и начинать с нуля?

А что делать ;)).
Как говорится: Хочешь тр.., женись. Хочешь сильно тр.. - купи машины (администри 1С ;))

(26) Ни в коем случае не сохранять данные средствами 1С (на всякий случай). Просто скопировать каталог полностью. Потом (ИМХО) надо взять все файлы и New_stru, убить cdx-ы и скопировать в отдельный каталог. Попробовать запуститься. Если не получится, взять копию 1-2-3 дневной давности и недостающие файлы копировать туда-же. А там по степени удачливость...

Да... я прибил бы... или выгнал... и нисколько не пожалел... ибо это попадалово... на...
Обязательное правило работы у клиента:
Копию до
Копию после
Протокол различий.

Восстановить то можно, но часто гораздо дешевле бывает откатить...

(26) Так она сама из франчей, насколько понимаю.
(28) А вот этого лучше не делать...

(29) Насколько я понял из одной из прошлых веток, Вы имеете некоторое отношение (или знакомство) с исх. текстом ядра 7.7. Так вот если это так, у меня к вам вопрос: если в ядро не добавлена функция бэкапа до (хотя бы до) изменения метаданных (конечно функция д.б. отключаемой, но она имхо д.б.), и юзеры с большим трудом находят где там бэкап (50 неочевидных выборов надо сделать, и они на это забивают), то кто в этом виноват, юзеры или все таки разработчики ядра?

Останки базы нужно разбирать ручками... и обработками ... и ни в коем случае как (28)...

Стоит такое очень дорого....
Если есть архив хоть какой с неправленым МД.... тогда надо перекидать туда остатки из обновленной базы... Еще раз - если базу не лапали руками - там много целого осталось ...

(30) Ну... это круто... исходный текст ядра...
Во-первых это не юзверь делал...
При чем тут метаданные? Они то как раз сохранены...
Речь идет про базу данных. Тут pit ответил 100% полно, добавить нечего...
Но дешевле бывает откатить... на любой период...

PS: telepat.dll в систему не встроишь... а посему бэкап лучше программеру ручками делать... и привить сие надобно сразу...
PSS: И опять pit прав... чем меньше базу после аварии лапали, нем легче ее восстановить...

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

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

Затем создать (найти, выпросить) пустую базу. И затем сконвертировать все назад из текстовых (dbf) файлов.

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

Базу еще вообще не лапали. Еще на стадии перехода с доса контора находится, так что ввести успели мало.

Это БорисГ злой? Ну и ну...

Все случилось вдруг и сразу.
Уронила Таня базу.

Чевой то по последним постам сильно смахивать начинает на кролиководство ....

Таня, а про обработочку можно подробнее?

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

(39) И не совсем скрипт а система резервного копирования. Например SecondCopy. Их полно и многие у меют не просто копировать, создавать архивы и хранить определнное число копий, а еще хранить их в разных местах и копировать их по сети. Так у меня на работе каждую ночь вся папка базы 1С (за исключением *.cdx) архивировалась на этот же сервер на этот же жесткий диск и хранилось последние 15-ть копий (на случай если нужно будет поглядеть что изменилось в базе, или если чего запорется как в (0), а не на случай краха винта), и еще каждый второй день архив копировался на другой сервер (file-server) и там хранилось тоже последние 15ть копий, а вот это уже на случай краха винта (т.к. копирование было через день, то хранилась соответственно история за месяц). А делалось это все программкой AP Backup, которая стоит копейки.
___
Искренне Ваш, Львенок.

Авто архивирование и архивирование при внесении изменений через конфигуратор - разные вещи ....

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

Да... видно не все так делают, раз полемика такая вокруг вопроса, который НЕ ДОЛЖЕН обсуждаться.
Еще раз.
Независимо от того, сдалал клиент резервную копию, или нет, специалист, производящий регламентные работы на системе ОБЯЗАН:
- сделать резервную копию ДО выполнения работ.
- произвести работы и сохранить протокол различий.
- сделать резервную копию ПОСЛЕ выпосления работ.
Это же касается и работ по установке ИТС и обновлению баз с него.

+45 В спорных ситуациях эти правила сильно помогают...

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

(45)+(46) Истина однозначно!  Тут и спорить нет смысла.

(47) Тоже вариант фиговый, к примеру клиент перепутал где какая база (а это бывает в 50 а то и больше процентов, ну не алё они) И будут работать дальше в старой, а потом может возникнуть спор по поводу что ты говорил (с месяцок назад)по поводу того в какой базе работать... Так что тут тоже

(34) Таня, коды элементов могли слететь например если разный тип поля или разная нумерация (в пределах справочника или во всем), если поправить обратно, то можно кое-что восстановить.
.
PS вопрос: база после обновления запускалась в режиме предприятия?

(42) У меня все так же, но к сожалению надо где-то приобретать или писать сторонние приблуды. Встроенное в язык 1С решение помогло бы не бегать, не искать и не писать/отлаживать на каждом клиенте один и тот же софт.

(44) Так из скрипта ротация архивов сама будет (может) вызываться. Тогда при проблемах как в (0) специалист придет и восстановит по архиву. А не будет бегать и индексы и DBF-ы лечить по ошметкам поврежденной базы.

(45) Ну и че тогда конфигуратор не отслеживает раз обязан? Зачем мозг людей загружать, если компьютер на то чтобы его разгружать? Технически может быть примерно так: если в конфе есть признак (например, в INI-файле), то конфигуратор не дает ничего с базой предпринимать, пока не сделают бэкап.

(48) Ложь это а не истина. Людям нельзя доверять, все должна делать программа.

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

romix прав, его бы в команду 1С разработчиков, но есть одно "но": http://www.1c-team.nm.ru

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

ой, грипп куринный
и разжижение мозгов впридачу

(53) Ты верную ссылку привел...
Так и хочется ему сказать "И почему ты не Нуралиев?"

Самое интересное в этой ветке то, что пробема ПРОКОЛА программиста, именно ПРОКОЛА, превратилась в обсуждение, почему это не сделали разработчики.
Система уже ЕСТЬ. И работать с ней надо именно с учетом того, что они ЕСТЬ.

И ответ ищется не как это сделать правильно, а как обосновать, почему это произошло... типа я не виноват...
Печально, увы...

А я и не говорю, что я не виновата.
Мне очень стыдно :(

(52) Милый Гере, опыта я думаю у меня поболе будет (так думаю только) и говорю основываясь на фактах, как не назови.....

(56) >"Система уже ЕСТЬ. И работать с ней надо именно с учетом того, что они ЕСТЬ".

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

1) Закрыть 1С
2) Пуск
3) Программы
4) 1С:Предприятие 7.7
5) Конфигуратор
6) Выбор базы
7) Авторизация
8) Меню Администрирование
9) Сохранить
10) Облом - блокировка метаданных
11) Сервис
12) Монитор пользователей
13) Меню Монитор
14) Активные пользователи
15) Обзвонить всех и попросить выйти из базы 1С.
16) Кто не откликается, пойти в My Compyter
17) Manage
18) Shared folders
19) Sessions
20) Close Session на каждой из сессий.
21) Для базы SQL рестартануть SQL сервер (net start mssql, net stop mssql).
22) Перейти к пункту 10 необходимое число раз
23) Меню Администрирование
24) Сохранить/для SQL - Выгрузить
25) Указать путь к файлу (пользователь должен знать, что такое диски, файлы и директории - т.е. должен быть квалифицированным пользоватьелем MS-DOS/Windows).
26) ОК
27) Пользователь должен правильно отреагировать на необходимость вставить другую дискету (типовые конфы 1С содержат много рекламно-графической хрени в BMP, и не помещаются на 1 дискету).
28) Интересно, кто из *пользователей* дойдет до этого пункта?

Вопрос: НУ НЕ УРОДЫ ЛИ ЭТО ЗАПРОГРАММИРОВАЛИ???!!!

Я должен еще раз повторить вопрос: а что мешает добавить пару функций в язык 1С? Функция ДатаПоследнейАрхивации() и  ВыполнитьАрхивацию(Путь) - неужели так сложно? Или религия не позволяет?

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

(60) Я ему про одно, а он свое...
Упрмство и нежелание слушать других... не самый лчший способ диалога...
Религия не позволяет... пообщайся с любыми разработчиками, не только 1С, поймешь...
"И почему ты не Нуралиев" ;-)
Маркетинг определяет функционал любого продукта. Пора бы это понять. К техническому исполнению это не имеет никакого отношения.

Вообще-то в этой ветке разговор совсем о другом. Но за этим отвлечением про это забыли.

(62) С какими разработчиками мне надо пообщаться, чтобы понять, почему бэкап в 1С через 28 действий, а не через одно? И никак нельзя из конфы напомнить юзеру, что он не сделал бэкап. Потом на юзеров наезжаете, что они тупые... А судьи кто?  :-)

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

(64) В зависимости от своих настроек (например, в INI-файле) каждый день, каждую неделю или каждый месяц. Хотя бы так. Иначе приходишь к буху, а у него база порушенная. Бэкапа не было месяца 4. :-) Мне воронку Инферно на свою голову не хочется иметь... ("Ночной дозор" Лукьяненко все читали?) :-)

(65)и что мешает это сделать другими средствами...

(66) Мешает то что у бухов, которые теряют базу, их как правило нет. Посмотрите что есть в виндах - чуть выключишь комп не так - сразу Scandisk c: (кстати скандиск лицензированный у Питера Нортона).

(67) Ну на это Белый Кот уже отвечал (61).
А часто бухи сервер включают? А для локалки можно и автозагрузке прописать

и если на то пошло то из конфы легко проверить и сообщить о необходимости сделать бэкап... коли такое доверяешь юзерам...

+Но если им наплевать (юзерам), то и мессага не поможет, а если не наплевать... то и сами научаться архивировать

(58) Дорогая Элли, такой подход еще ни разу не давал осечек... Хотя может мне просто везло на клиентов, и они спрашивали, или сами приходили к правильному выводу

(71)тебе везет, а вот как магазин сядет, отработает недельку другую до конца месяца... тогда узнаешь где раки зимуют ;-)

(72) отмажусь, будет вина бухгалтера

(73)везет вдвойне ;-)

(74) шутка, конечно, проблема, то останется моей

(76)порой даже очень большой кровью...

а то что, в (45) полезно знать не только фра и фри, но и фикси... ибо последствия могут быть кровавыми как в прямом, так и в переносном смысле...

Мдя... BorisG ведь аксиому спеца сказал..
Предохранятся знаете ли нужно во многих ситуациях(точнее во всех) :) Строка 1 Абзац 1 : Забэкапся от греха подальше :)
Все что вытащила автор поста - респект конечно. Опыт - сын ошибок .. далее по первоисточнику.

Вообще то 4 строки инструкции для фра вообще то пишутся в таком стиле

1.Сделать копию ДО РАБОТЫ
2.Сделать вторую копию ДО РАБОТЫ
3.Чтобы не пролететь - сделать ТРЕТЬЮ копию....

Псоледний пункт. Сделать копию ПОСЛЕ ОБНОВЛЕНИЯ .... Пароль на архив юзерам не сообщать ...

(79) pit, ну кто помнит ленты, так и писали... ТРИ копии...

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

(69) И как же я проверю что базы были заархивированы? Это было бы здорово, если бы такая функция в языке была. Ее то я и хочу.

(70) Разумеется блокировка должна быть такой, что например юзер не сможет перейти на новый период, или начать новый день, пока не сделает бэкап. Если юзеров это взбесит, то в конфе или ini такая настройка - включить данный режим или нет.

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

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

(81) Упрямство, достойное лучшего применения... и нежелание внимательно слушать...
Я не о юзверях говорю, для них есть средства...
Я говорю о СПЕЦИАЛИСТАХ, выполняющих РЕГЛАМЕНТНЫЕ работы..., а это совсем из другой оперы...

(82) Хороший метод спора:

1) Сказануть с умным видом общеизвестную истину (надо делать бэкап!).
2) Сделать вид что оппонент с ней не согласен.
3) При любых репликах оппонента goto 1.

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

Весь день сегодня делая архивы клиентские, почему то вспоминала, что самое прикольное не Татьяну (с ее пролетом) а БорисаГ. :-)))

(84) Вы делали бэкап до или после падения юзерской базы? :-) И сколько времени в таком режиме архивации (когда все делает специалист) проходит между двумя ближайшими бэкапами?

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

(85) 1)после падения юзерской базы бэкап с нее уже не сделать, умник.
2) Столько, сколько уходит у меня времени на мои работы с клиентской базой.

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

(87) Да, конечно - а то некоторые пытаются после падения базы сделать хоть что-то. :-)
А зацените, хороша же работа: в других системах (скажем в виндах) для установки патчей (обновлений) надо просто запустить setup.exe, а в 1С надо выполнить кучу административных действий с большим риском ошибиться и потерять базу... Имхо разработчики 1С не заморачивались юзабилити. :-)

(88)без проблем...

(88) сравнил...

(89) Я имею в виду не простое копирование DBF куда либо,
а отслеживание ситуаций копирования на несколько дискет, а также отслеживание когда файлы в работе (залочены, изменяются и т.д.).

(89) Я имею в виду не простое копирование DBF куда либо,
а отслеживание ситуаций копирования на несколько дискет, а также отслеживание когда файлы в работе (залочены, изменяются и т.д.).

(91)тоже решаемо...

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

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

(95) До какого-то момента можно на дискетах, потом уже потребуются брелки, пишущие CD и т.д.

В плане автосохранения 1С сильно отстает, скажем так "хромает на обе ноги". Взять хотя бы такой продукт как "Катарсис" (прога для учета безработных, работает в службах занятости половины России, написана на FoxPro под Дос). Так там есть возможность автосохранения с любой периодичностью, вплоть до отдельного DBF файла, лишь бы в назначеное время к программе был подключен любой пользователь и существовал путь сохранения информации... А кромя того данная система поддерживает полностью все операторы языка SQL...

Можно для примера взять и такой продукт, как Windows 98. В момент загрузки он сохраняет на диск шесть последних копий реестра (в архивах cab) и выполняет их ротацию (удаление наиболее старых версий). Так что можно не переустанавливать винды, а распаковать архив с реестром. В 1С гораздо более ценные данные, а резервное автосохранение не предусмотрено. Ну это видимо чтобы юзера не расслаблялись, и были всегда на стреме...