Как посмотреть, какие документы, справочники были изменены в SH за определенный день?
Как посмотреть, какие документы, справочники были изменены в SH за определенный день?
Сервис - Протоколы
Печальная ошибка...
0. Попробовать бекап/рестор - но вряд ли получится.
1. Пробовать прогнать через Shc.exe
2. Восстановить резервную копию "за вчера" где ошибки еще нет и вбить заново (или перенести) недостающий документооборот.
3. В противном случае на ремонт в UCS (может быть долго и не бесплатно)
Да, собственно из-за прекращения создания автобэкапа и обратили внимание на проблему (галка автостопа сервера стояла).
Нет, не помогает.
Так и сделали. Вот только группового импорта\экспорта нет в SH, поэтому при большом кол-ве документов это задача не из простых.
Так и есть. Не бесплатно, да и вообще сказали, что не факт, что восстановят.
О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли. Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД? Могут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?
Ну быть уверенным на 100% что в момент работы (на запись) с БД не вырубился свет - вы не можете.О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли.
Этого думаю даже в UCS не знают. А если знают, то не скажут. А если скажут, то не нам...Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД?
В философском смысле вопроса ответ будет Да. Причина любого сбоя, так или иначе, действия пользователя. Если с БД никто бы не работал, то она бы и не поломаласьМогут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?
С практической точки зрения - Нет.
Суть проблемы в следующем (это мои догадки и теории): Файл БД разбит на страницы, данные хранятся в страницах. Но это не значит что 1 страница это какой то конкретный 1 документ или элемент справочника. Документ может занимать несколько страниц или в одной странице их может быть несколько. Такая структура хранения свойственна для некоторых типов баз данных (например IB и FB имеют похожую архитектуру).
При изменении данных страница перезаписывается целиком. Т.е. если у нас в 1 странице лежит 2 документа. Мы меняем первый, он успешно записался, но при перезаписи той части страницы где хранится документ №2 произошел сбой (например отключение питания), то получится что битый документ №2 хотя его никто и не правил.
На www.ibase.ru где то была статья, в которой описываются типичные причины повреждения баз IB/FB Это конечно не совсем про UCS, но учитывая что архитектура схожая это статья применима и к базе SH. Если интересно, найдите почитайте...
Из-за того, что железо несовершенно.Из-за чего обычно происходят такие сбои в БД?
Что ошибка в проектировании архитектуры - очень вряд ли, т.к., основы проектирования СУБД давно разобраны по косточкам - это раз; у UCS огромный опыт построения СУБД - это два.
База сидит целиком в памяти, вряд ли Вы применяете память с контролем четности, пролетела ошибка - и привет. На то и нужен бэкап.
Алексей Аркадьев
Когда заказчик ищет волшебника, то чаще всего он находит сказочника.
Если у Вас есть вопрос по поддержке - напишите его на форуме, я обязательно отвечу, если знаю ответ.
Если Вам нужны какие-то файлы, пишите на почту: support@carbis.ru, но вначале посмотрите в разделе для скачивания.
Для коммерческих вопросов:
+7 (495) 740-49-91, или на почту: sales@carbis.ru