Доброго всем времени суток.
Суть проблемы такова: имеется приложение, работающее на промышленном компьютере, которое раз в секунду должно записывать текущее состояние датчиков в БД. Это не основная задача (просто лог с возможностями выборки), поэтому был приделан ахсекс. Добавление идет через дао из С++.
Во время работы БД упала. Специфика эксплуатации в том, что компьютер не паркуется, а выдергивается из розетки. Однако БД упала именно во время работы, а не при старте/запуске.
Собственно вопрос - виноват ли аксес, и если да, какую БД выбрать для этих целей?

Рыжий Кот

можно попродробнее?

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

ЛП
Во время работы БД упала.
Бывает такое с аксесом. Прямыми руками разработчика ситуация немного исправляется, кривыми руками - тока усугубляется.

Спасибо за критику. Пошел думать как улучшать процедуру добавления одной записи в одну таблицу.

Собственно вопрос - виноват ли аксес
Да.

Спасибо за краткость.

и если да, какую БД выбрать для этих целей?
Любую не файл-серверную. Т.е. не аксес, не фокспро, не парадокс и всякие прочие извращения. Файл-серверные БД не расчитаны на работу в таком режиме.

Попробуйте какой-нибудь MS SQL Server для начала. По крайней мере переход с аксеса на MS SQL Server будет менее трудоемким, чем на другие сервера.
Спасибо за конструктив.

Yo!!значит у вас плохо с политиками. трудяги не должны физически дотягиватся до кнопочек. комп в сейф к нему упс и все проблемы. вырубится питание сам зашатдаунится сам потом поднимится.

На кнопочки они всё таки должны нажимать - например сбросить датчик, переключить режим и т.п. И вообще это скорее к руководству.
Вот по поводу упс, в сейф и все проблемы. Все ли? Я ж говорю - база упала прям во время работы, без скачков напруги и вырубаний. Штатный режим - добавление одной записи в секунду. Размер к тому моменту был небольшой - около 10 000 записей.

Задам более конкретный вопрос. Если сменить аксес на какой нибудь парадокс, будет лучше в плане устойчивости, или в таком режиме (между включением-выключением) аксес падать не должен? Если не должен, но падает то это что - по любому СКР или всё таки повер офф может быть тому причиной?

ЛП
Руки кривые
Железо кривое
Операционка кривая
Сеть кривая (если база сетевая, а не локальная)
Офис криво поломан
Расположение звезд кривое
Выбирайте что больше нравится

Железо специальное для промышленных компов - обычные горят, как и у всех белых сов :). Операционка - икспи лицензия, офис тоже, база локальная, консультировался у астролога - меркурий стоит в раке, значит всё должно работать :). Вы уверены, что больше нет никаких вариантов? :( . Точно? Что ж, правда порой бывает очень горькой :)).

VoDAВозможно немного не в тему, но у самого на mdb работала компания. Так вот Access сам мог заносить туда сбойные записи, от которых у него же съезжала крыша. Происходило при мне, сеть 100Mb, сервер 2003EE на УПС, питание ни у него, ни у клиентов не падало.

А с чего сия проблема воззникла не разбирались? И как, если не секрет, с ней успешно боролись?

SarinСдаётся мне что нужна БД с транзакциями. В аксесе вроде нетуж.

А где есть? Тока маленькая локальная, а не оракул какой нить. Что б юзать можно было просто. Ахсекс подходит вроде по всем параметрам, кроме устойчивости :) .


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

Alexey2005К сожалению, не озвучена версия ОС на этом многострадальном сервере. XP и 2003 windows позволяют настроить управление питаем. Т.е. при нажатии на кнопку Power компьютер не мгновенно выключиться, а выполнит, напиример, правильный shutdown. Это спасет и базу и ОС.
В случившемся же скорее всего виновата файловая система. У которой после многократных "выключений рубильником" нарушилась целостность индексов и корректность адресации. При очередном добавлении в файл запись прошла на "кривой" адрес и все ...

Озвучено было (винь ХР), но это и не сервер - сети там нет (хотя если имеется в виду сервер БД, то да). Комп промышленный - у него не кнопка, а переключатель ON/OFF :). Файловая система ntfs, так что вроде как должно всё номально быть (по крайней мере лучше чем с фатом).

По поводу трудовой дисциплины - очень тонкий политический вопрос, т.к. начальник нашего отдела и начальник производственного отдела как говорится "четыре разных человека". И нельзя сказать, что второй начальник, так же как и рабочие, счастливы лицезреть светящийся монитор на своем рабочем месте. Более того, из одного отдела нам был привезен комп у котого ЖК экран был поврежден, несмотря на то, что находился за оргстеклом!!! Поврежден был надежно и по русски - ЛОМОМ!!! :). Говорят, правда, случайно. Так что боюсь от периодического вырубания питания даже упс не спасет :).

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

Таким образом задача сводится к следующему - обеспечить корректное отображение состояний датчиков (сделано) и постоянную запись в БД в таком вот режиме. Понимаю, звучит дико, но мне уже даже интересно стало.

Например, сделал такой ход - при нормальном завершении работы весь файл mdb бэкапится. Если во время запуска или работы всё упало - текущий файл закрывается, запись начинается в копию. Текущий файл помечается как сбойный и не трогается. При необходимости можно средствами самого аксеса битый файл восстановить. Вроде логично. Не работает :(. Во первых странным образом могут рухнуть оба файла сразу (при том что работа ведется с одним). Во вторых если подмена файла прошла успешно - система востановления аксеса теряет процентов 80 имеющейся информации.

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

З.Ы.Сейчас буду пробовать ставить огнептицу. посмотрим что из этого всего выйдет.

VoDAА сеть подрубить можешь?

Нет. Никак. Ни слаботочные каналы, ни волокно, ни лазер, ни GSM, ни радио. Была б там сеть, было б понятное дело проще.

1024так какой смысл в БД? Там же только запись данных. Пусть всё валится в плоский тект, когда файл больше, скажем, 100 кб., создаётся новый с именем датавремяrandom.

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

сломать текст трудно, в любом случает в блокноте посмотреть можно.

Это и было сделано с самого начала. И проще и быстрее. Только потом начали накручивать возможности - показ статистики, графики всякие, для мастера. Кроме того в разные моменты времени действующее значение имеют случайный набор датчиков (т.е. каждая запись в таблице может содержать случайные пустые поля). Именно пустые - любое число можно спутать с действительным значением датчика (даже NaN). Кроме того парсить кучу файлов для построения графика работы какого-нибудьд параметра, учитывать, что они могут быть битые, это совсем не "select * from log where date>27.07.2005". И вообще БД сказал прикручивать началник отдела. На будущее видимо.