Ура! Кажется починился!
А вышло вот как... у меня ссылки на файлы прописаны в таком виде: \\server\и так далее... так как все файлы лежат на сервере и к нему подключен сетевой плеер и второй ПК, на самом сервере киношки я не смотрю. Так вот, решил обратно переписать пути не через сеть, а напрямую: H:\films\И так далее... соответственно, программа увидела все те-же файлы и предложила переписать путь к файлу (просто наиофигенская функция, никто так не умеет, в очередной раз порадовался) и в какой-то момент при замене пути программа вылетела с ошибкой. Ок. Захожу в расширенный поиск и задаю "Расположение носителя содержащее в пути \\" получил список и ПЕРВЫЙ фильм и оказался "Битым". "Вставая" на него получаю ошибку указанную в первом посте этого топика (ну может цыфры другие, не суть важно, важно, что запись не читается). Запустил FireBird Maestro нашел запись с этим ID (номер фильма) и просто У Д А Л И Л. Проделал замену пути к файлу дальше, выявил таким макаром еще одну битую запись (в итоге их было две: 4645, 4355) удалил её, закончил смену пути. Нашел новые файлы (ими конечно оказались удаленные ранее фильмы) заново оформил к ним карточку и оптимизировал базу! И всё получилось! ЕЕЕ!!! Единственное... как быть дальше... ПОЧЕМУ база впринципе "портится"? что такое с ней происходит? Просто эти записи еще недавно абсолютно точно были не битыми. Да, пару раз приходилось по разным причинам жОстко выходить из PVD путем убивания процесса, это могло стать причиной? Это и пугает, что не знаешь, закрывая базу, что получишь завтра, базу с ошибкой или нет. А каждый раз оптимизировать базу весом под 8ГБ очень сложно, слишком долог этот процесс . Вот бы хоть механизм поиска битой записи как то разработать, что-бы в случае чего, можно было просто удалить поврежденную запись и заново внести её в каталог... раз нельзя застраховаться от повреждений, то вот хотябы упростить поиск поврежденной записи...
