Здравствуйте.
Такая ситуация - сбойнул файл... Клиническая картина: будто 2 таблицы ссылаются на одну и ту же область данных.
select * from Camera и select * from Plugin_Param дают одинаковый результат, только разбит на столбцы соответствующие запрошенной таблице. Удаление из одной таблицы записи, влечёт за собой и удаление из второй. Ключей нет, триггеров нет.
Помогите, пожалуйста, понять две вещи:
- Это лечится или нет?
- Как такое могло произойти? Хотя бы теоретически.

Спасибо за подсказку, но это не лечение, это запасной/обходной путь.
В моей ситуации я именно так и сделал - всё скопировал, лишнее покикал и заработало. Но если (когда) это повторится, да ещё и на других таблицах, и не на 2, а на 3, то надо будет делать аналогичное, ориентируясь на новые условия сбоя. Уследить за всеми экземплярами систем в моей ситуации зело затруднительно. А как известно, если неприятность может случиться, то она случится обязательно...
Если же есть лечение, то я могу написать функционал, который сможет это фиксить, ну или пытаться фиксить... Сейчас мне пока что видится только путь, связанный с изучением структуры хранилища SQLite, но надежда что такое уже с кем-то случалось и удачно решалось, всё ещё жива.

Аргумент... Дошедшая до меня статистика - два случая на примерно 200 экземпляров системы за полтора года. Сколько таких сбоев решено самостоятельно админами, мне неизвестно. Но я не бизнес-специалист, я технарь. Мне нужно решить этот вопрос... Если я буду выбирать путь "забить", то мой результат будет превращаться со временем в очередное говно, которого итак много о тех, кто не любит своё ремесло. Также, свой условный час я не могу оценивать выше, чужих человеко-дней или тем более неприятностей, связанных с простоем системы... Не зазвездился ещё до такой степени :) .

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

ЗЫЖ Но нет, так нет... Отсутствие ответа тоже ответ :(.

Спасибо, постараюсь вникнуть.

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

Вполне возможно, что мои изъяснения не на 100% грамотны и не достаточно доносят мою мысль, противоречат и т.д. Но это не отменяет самого факта возможности решения проблем последствий. Я не очень понимаю - вы хотите меня убедить что это невозможно? Если так, то зря. Очень даже возможно. Схема проста - область данных, на которую ссылаются несколько ссылок просто копируется. Это устраняет проблему когда при работе с одной таблицей получается эффект для другой. Далее - скулайт, каэш, хранит всё в строках, но в соответствии с типами полей теперь мы бежим по строкам в размножившихся таблицах и удаляем те записи, в которых есть несоответствие типов данных. После этого наверняка что-то ещё останется, но из трёх проблем уже решено 2: БД более не испорчена и селекты внутри софта не сваливаются из-за несоответствия типов данных.
Остаётся выяснение причины и последующие изменения при работе с файлом. Когда я выясню причину я не знаю, но знаю что после описанных выше изменений, проблем у пользователей и админов будет меньше.

ЗЫЖ Ну, предположим, что вы делаете такие решения, которые всегда решают абсолютно 100% проблем... Я ещё не такой, поэтому считаю, что если можно решить даже 10-20% проблем, то это уже имеет смысл.

Вернулся к этой проблеме, вот что удалось найти...
На сайте скулайта в разделе загрузок есть набор тулзин, в котором есть программа sqlite3.exe. Далее берём сбойный файл и поступаем с ним так: Теперь мы получаем дамп, в котором все сбойные данные переместились в таблицу lost_and_found. На основе этого дампа создаём новый файл: В полученном файле не будет проблем с типами данных, теперь можно поработать с ними логически.
Тулзина, естественно, позволяет сделать и обычный дамп, но при обычной выгрузке не происходит проверки на типы данных и дамп обязательно надо обработать руками, чтобы убрать несоответствующие структурам данные.

Конечно, в данном конкретном примере, восстановление против ручного копания не даёт выигрыша по времени, но в другом случае речь шла о 6000+ записей, из которых сбойными оказались 691 запись, а с таким объёмом данных поработать проще. Да и потеря индекса видео, где это произошло, теперь не за день, а за полтора-два часа.

Надеюсь кому-нибудь пригодится эта инфа.