Есть архив, тем не менее, задам почти риторический вопрос: есть ли способ починить?

даже ИБП нет? вот жмоты

(0) это знак!

CHKDSK

(1)ИБП не нужен я считаю, тупо развод на бабки

(4) надо было поселить буха на ноутбук, там есть встроенный аккум!

(3) Если был открыт по сети,то велика вероятность,что занятое файлом место освободилось.
В этом случае,очень сложно его найти.
Если же только локально,то восстановление размера по занятым данным chkdsk сделает успешно.

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

(6) если даже место освободилось, то можно un-deleat'ом каким-нибудь, который сканирует поверхность диска на блобы похожие на файлы.

даже если и восстановите файл, то он будет битый и непригодный для работы. это вам не dbfка

Устройство ntfs предполагает,что все данные о блоках файла живут в объекте описания файла в мастер-файле.
Если там что-то пропадает,то блоки файла автоматически свободными не становятся,так как они должны добавляться в файл свободного места.
Если потерялся один файл,то его можно найти,а вот если пропало много,то поиск - это очень нетривиальная задача.

Ещё,некоторой особенностью ntfs является то,что запись полного блока файла может попасть в другое место,нежели он располагался - в результате,мы может при восстановлении получить кусок прошлой версии.

(0) восстановлю базу за 10 000 000 руб полгода времени

R-Studio программу можно попробовать.

(0) аватарка подходящая.

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

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

Лет наверное 8 назад была похожая ситуация, правда при обновлении, тоже свет рубанули. Выяснил, что создается копия в каком-то там файле. Странно, что ТС не посмотрел файлы по размеру.
У файловой 1С своя встроенная СУБД, она не может быть настолько всратой, чтобы обнулять все записи.

(9) ---> "даже если и восстановите файл, то он будет битый и непригодный для работы. это вам не dbfка"

А что dbfка, она неубиваемая, что ли?

(18) вообще, часть данных из нее достать можно, если она битая. а вот из 1сд - вряд ли

(17) ---> "была похожая ситуация, правда при обновлении, тоже свет рубанули. Выяснил, что создается копия в каком-то там файле"

Это же вроде если реиндексация таблиц запущена, тогда просто создаётся новый файл 1Сv8.1CD, а старый как-то переименовывается и не удаляется, пока новый полностью не создастся.

(19) ---> "часть данных из dbf достать можно, если она битая. а вот из 1сд - вряд ли"

Да вроде из из 1CD чего-то достают умельцы (если конечно файл 1Сv8.1CD не стал размером 0 кбайт, как у ТС), какие-то там вроде были специальные танцы для этого, типа такого:
https://catalog.mista.ru/1c/tools/166557/
https://catalog.mista.ru/1c/tools/166557/

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

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

Базу из архива восстановил, недостающие документы внёс, теперь новая напасть: был обмен по 1С-ЭДО, и обмен с ФНС. Документы в базе есть, а электронных документов - нет.

По результату, получил геморрой с ЭДО. Электронные документы утеряны. У диадока и сбис документы хранятся на портале, у Калуги-астрал документы хранятся в базе 1С. В общем, "делай архивы почаще, сынок".

(25) не используйте файловые базы!!! нет денег на сервер, уходите в облака 1с

(26)Да бред же :) Файловая база норм, просто не делать бэкапы в 2023, ну это я хз.. Сами себе злобные буратины.

Я ещё в 2009  на ИС
статью выкладывал (не нашёл, удали черти)

Берём файл большой фильм 4 гб.
Удаляем вручную, есть куча способов чем и как восстановить

Но, если это файл удалить
Макросом VBA - KILL()
Или 1С (Удалить файл() )
удивитесь и не поверите пока сами не про экспериментируете

(28) ну давай растяни баян, открой интригу

(29) Че, ты чё?

(30) ну это... типа.. jsnm это только окгда сам на грабли настпуаешь? ;-)

(18) В конце 90-х была база фвйловая ТиС 7.7 на сервере Novell Netware 4.11.
Там ФС точно неубиваемая была - очень хорошие опции для восстановления состояния на любой момент

(32) ну так в ЖКК тогда прямо писали что для 77 рекомендуется нетварь.
я как-то пошел (трудные времена были) устроиться инженером-погромистом в пейджинговую компанию, для проверки дали установить нетварь. проколоупался часа три - оказался диск, на который надо было поставить нетварь - битый вдребезги... так и не срослось в итоге у меня стать пейджер-джаном

(33) А я тогда "собаку" съел на этой нетвари тогда - пока не накатишь сервис-пак sp9, как щас помню - 4.11 нормально не работала.
Диски - лицухи и дискета на 10 юзеров до сих пор лежат...

(34) да... винда тогда нетварь скосила... а ведь была еще и мух-пополам...

(35) Нетварь была отличной серверной ОС, но винда победила удобством администрирования - терминальные службы (особенно в связке с Citrix Metaframe) позволяли централизованно решать кучу проблем пользователей мгновенно, даже не поднимая попу от кресла.

(27) "Файловая база норм"..."ИБП не нужен" - Ваша фамилия, случайно, не Остер?

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

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

(37) (38) Нет всё именно так как я и сказал. ИБП не нужен, файловая база норм.

Если ты пробуешь своё дело, купил базовую БП за 3600, поставил архиватор чтобы при включении компа происходило копирование БД и всё, работаешь.
Или что сервер купить или же за облако платить каждый месяц?
Так-же и ИБП, зачем он? Чтобы батарейки в нём менять каждые 3-4 года?
Чтобы не случилось, базу можно восстановить из копии на начало дня.
Если сильно переживаешь за винт, делай копию раз в неделю на внешний винт например ещё.

Другое дело когда у тебя совсем другие объёмы, тут да, без сервера и ИБП на сервак не обойтись.

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

(0) 1 раз было такое у клиента, восстановил из истории файлов (сейчас "Предыдущая версия") (стандартная виндовая фича теневого копирования) на утро пятницы, дело было в понедельник. Счастью не было предела.
Сопровождали не мы.

(40) А если во время установки обновлений, рубанётся электричество, то можно и винду переустановить. Ведь каждый бухгалтер должен это уметь. Ага.

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

(43)Живу в деревне, вокруг все работают на компах без ИБП, всё норм, ЧЯДНТ? Я говорю вам факт как реально работают люди, а вы утверждаете что так работать нельзя. Но реальность такова, что тысячи так работают и проблем нет.

(42)Шанс на это настолько мелкий, что дешевле заплатить 2к эникейщику чтобы он поставил тебе винду и восстановил базу из архива раз в 5 лет, чем альтернативы предлагаемые вами.

(44) ну у меня реальность немножко другая. У меня она такая, что разок скульная база 50-гиговая померла из-за того что ИБП был неправильно настроен - я подрочился с бэкапами денек в условиях жесткой подгонки со стороны руководства, обошелся малой кровью, несколькочасовой потерей данных - но все равно понял, что мне оно категорически не надо. Поэтому упсы наше все, свежие аккумы наше все, грамотная настройка - тоже.

(45)Я вам про файловые базы и микробизнес, а вы мне про скульные базы в 50 гигов :)

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

я попытался проделать всякие типовые манипуляции типа DBCC CHECKDB, но они не привели к быстрым приемлемым результатам, соответственно, я это дело бросил и взялся за бэкап.

(44) "Шанс на это настолько мелкий," - Когда в городе - да. Но стоит от него отъехать - и перебои с электричеством - это уже реальность, при которой ИБП просто необходим, если не хочешь потерять данные.

(44) "тысячи так работают и проблем нет." - Собственно, данная ветка опровергает твоё утверждение :)))

(50)Блин точно, всё плохо, предлагаю вам написать в 1С, чтобы запретили файловые базы :)

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

Не нужен - не значит противопоказан, если он будет, то хуже не станет.

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

(51) А никто не говорит про запрет файловых баз. У тебя явно проблемы с логикой.

(46) владельцы-пенсионеры ларьков на рынке с десятилетними ноутами идут на курсы и учатся бэкапить на флешку. Ключевое наверное владельцы
на авито Ибп Ippon Smart Winner 3000 4000р + набить новыми аккумами, где тут можно экономить?

(54)Ну перечитайте посты (26) и (27), может быть вы зря ко мне придираетесь за то что я пытаюсь отстоять возможность использования файловых баз? :)

(56) Я? Вовсе я не придираюсь за это. Перечитай мои посты ещё раз. Всё-таки с логикой проблемы.

(55) согласен. Если человек использует в качестве сервера обычный комп, можно даже взять 500-650 ВА модель, этого хватит, чтобы нормально погасить комп в случае сбоя в течение 5-10 минут.
И раз в несколько лет заменять батарею стоимостью в полторы тысячи рублей.

В вы (54) пишете - "Никто не говорит про запрет файловых баз", в (26) говорят - "Не используйте файловые базы", на что я возражаю в (27) и говорю что файловые базы имеют право на жизнь, но нужны бэкапы. Но видимо с этим не согласны и в (37) пишете мне - "Файловая база норм"..."ИБП не нужен" - Ваша фамилия, случайно, не Остер? Тем самым переходя на личности.

Походу у меня и правда проблема с логикой раз я вижу тут придирку какую-то. :) Извините что ввёл вас в заблуждение, я был неправ.

(51) А давай лучше напишем петицию о возврате к формату DBF )

(60) Там наверное какие-нибудь свои грабли имеются, нет? Не зря, наверное, DBF пал жертвой прогресса, или зря всё-так?

(60) Используйте клюшки, там это реализовано :)))

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

(61) Разве что ограничения на размер файла, связанный с 32-битным адресом в индексе. Ну подумаешь. Отказаться от формата индекса cdx, ввести новый формат с 64-битным индексным файлом. А базовый формат dbf ограничений не имеет.

даже во времена семерки многие вещи касательно хранения данных в ДБФ делались костылями. Достаточно заценить, как хранятся строки неограниченной длины :)

(0) ---> "файл 1Сv8.1CD стал размером 0 кбайт"

А почему именно 0 КИЛОбайт?
Насколько вообще уместо использовать кратные единицы измерения для нуля?

(63) Но это же не принципиальные ограничения формата, а особенности реализации, так что всё это должно быть решаемо, вроде.


(64) ---> "базовый формат dbf ограничений не имеет"

Я почему-то тоже так и подумал.
Получается, раньше было лучше.
Надо писать петицию.

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

(65) Непонятно почему не использовали штатный BLOB из формата DBF v4, а изобрели свой велосипед.

(67) не, ну как решаемо... Если вы это будете решать принципиально, вы в итоге получите уже не DBF, а что-то другое.Потому что утратится совместимость.
Например, запилите свой тип данных новый к имеющимся - значит, старые просмотрщики и т.п. софт этот файл уже полностью или частично не откроют.
То же и с индексами.
Собственно, 1С уже это сделала, создав новый формат 1CD, который несовместим с DBF. "Я сам Платон! С той разницей, что я - не он" :))

А если вы это решать принципиально не будете, вы получите адские тормозные костыли, которые вдобавок будут жрать лишнее дисковое пространство.

(70) Так сохранить совместимость по данным, это уже хорошо. А индексы можно было и свои придумать, их пересоздать всегда можно.

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

все эти варианты зовутся словом "костыль". Одни костыли будут менее кривые, другие более.

(72) Какие проблемы писать юникод в UTF8 в обычные строки? Да и на практике юникод не нужен. Он только процессорное время жрёт и место. То есть, при создании реквизита тупо ставим галочку "юникод", чтобы в реквизите хранить имена китайцев, а по умолчанию и без него жить можно.

(74) > Какие проблемы писать юникод в UTF8 в обычные строки?

Да никаких, кроме той, что они для этого не предназначены. Будут проблемы с длиной поля - если там ограничение на 255 символов, то в случае с UTF8 реальная длина строки, которая туда поместится, может быть довольно маленькая. Штатная индексация тоже работать не будет. Короче, так-то можно, вот только сначала надо дофига чего сделать :)

> То есть, при создании реквизита тупо ставим галочку "юникод", чтобы в реквизите хранить имена китайцев, а по умолчанию и без него жить можно

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

(41) >> 1 раз было такое у клиента, восстановил из истории файлов (сейчас "Предыдущая версия") (стандартная виндовая фича теневого копирования)

Вашему клиенту как-то сильно повезло.
История файлов по умолчанию была включена только в какой-то старой версии винды (в 8-ке кажется). Во всех последующих по умолчанию она выключена.
К тому же (опять таки по умолчанию, если просто история файлов включена, н оне настроена дополнительно) версионируются только файлы в пользовательском профиле (Мои Докуенты, Рабочий стол, Изображения и т.п.). Значит либо база была в "Моих Документах", либо служба истории файлов была дополнительно кем-то настроена.

Так что эту историю скорее можно приравнять к ситуации, когда настроено резервное копирование.

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

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

(15) это сарказм надеюсь

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

(78) А СМСки на телефонах в начале нулевых транслитом писали, да. Я это тоже помню, я тоже суко мамонт. Но с тех пор вроде как что-то изменилось. И если вы хоть раз делали приложение, которое одновременно показывает несколько языков и хранит эти данные в БД - то как-то не вполне понятно, зачем от этого отказываться и связывать себя какими-то дурацкими ограничениями.