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

Продолжение темы в исходной «Жертвы тиража«. Писал где-то в 2006-2007 году. Нашел как черновик, решил опубликовать, чего пропадать тексту 🙂 http://www.osp.ru/os/2005/11/072.htm7 проблем программной инженерии середина 80-ых — Читать на сайте автора.

Если при restore бэкапа InterBase gbak вам выдает ошибкуdecompression length errorто скорее всего бэкап был сделан другой (предыдущей) версией gbak (или InterBase).В этом случае или надо взять gbak.exe от нужной версии, или сделать бэкап повторно с указанием опции -expand. Получается, что у InterBase опцию -expand желательно указывать при бэкапе? И у Firebird? Читать на сайте автора.

Наконец-то дописал статью про шифрование баз. http://www.ibase.ru/devinfo/ib-encrypt.htm Вопросы можете задавать как удобнее — либо здесь в комментариях, либо на email в конце статьи. Читать на сайте автора.

Еще в сентябре 2013 года, на презентации RAD Studio XE5 я докладывал про IBLite, как с ним работать на мобильных устройствах.http://www.youtube.com/watch?v=YMs1buTLI1Y Однако сразу же возник вопрос — где находится база данных на смартфоне, как ее «вытащить», обновить, и так далее. Покопавшись в разных местах, ясного ответа не нашел, а экспериментировать вслепую, или перечитывать тонны абстрактной документации по Андроиду, не хотелось. И вот, к счастью, нашелся человек, который просто и понятно объяснил, где что и как: Рекомендую блог Андрея Ефимова, особенно статьи: Deployment Manager или куда ещё можно задеплоить файлы Получаем список доступных устройств хранения информации(должна быть правка под мою Sony Xperia V) Обновляем файл базы данных без перезапуска приложения(тут про SQLite, но можно легко переделать и на IBLite) Собственно, эти статьи, и тестирование кода явились как бы хорошим пинком в правильном направлении, в результате которого я форсирую проведение экспериментов в этой области. Что выйдет быстрее — вебинар с Embarcadero или статья в блоге, пока не знаю. Ждите новостей. Читать на сайте автора.

InterBase явно опережает Firebird в захвате рынка мобильных платформ. Вместе с Delphi XE4 разработчики получили возможность использовать InterBase (в варианте IBLite) на iOs, а для Android уже есть IBLite в редистрибутивах бета-версии Delphi XE5 (которая выйдет в начале сентября). Вот пример приложения, работающего с IBLite на iOs и Android:http://blogs.embarcadero.com/sarinadupont/2013/08/26/cooking-with-interbase-on-android-and-ios/ Я пока еще IBLite для Android не прикрутил, но сделаю это в ближайшие пару дней. Здесь можно посмотреть технические спецификации IBLite и IBToGo. Напомню, что обе эти варианта InterBase являются встраиваемыми (embedded), т.е. являются подключаемой к приложению библиотекой, и одновременно выполняют как функции локального сервера, так и могут работать с удаленным сервером InterBase в качестве клиентской части. p.s. у Firebird для мобильных устройств пока есть только клиентская часть в виде драйвера JayBird, и то в варианте, подкрученном одним энтузиастом. Читать на сайте автора.

На этот пост спровоцировало разбирательство на sql.ru. Там много страниц, можно не читать, здесь я обобщу полученный опыт. Итак, СУБД Firebird и InterBase обычно используют файловый кэш при работе с БД. Вернее сказать, не «используют кэш», а при открытии файла БД указывают опции, которые включают или выключают этот кэш в определенных случаях.Одновременно, они используют свой собственный кэш страниц БД. Самый первый и известный случай изменения режима , это режим Forced Writes, т.е. в терминах CreateFile (Windows) включение (ON) или выключение (OFF) флага FILE_FLAG_WRITE_THROUGH. При ON операционная система осуществляет запись сразу на диск (или в контроллер raid, и т.д.). При OFF операционная система кэширует изменяемые страницы в RAM (подробнее о режимах кэша Windows).Однако, у Firebird и InterBase существует понятие careful writes, когда изменяемые страницы записываются на диск в таком порядке, чтобы в случае внезапного сбоя (например, reset) база данных осталась максимально целой. Поскольку при OFF (включенном write cache ОС) порядок записи определяется операционной системой, а не СУБД, в случае reset БД может оказаться, скажем, в «физически нецелостном» состоянии. Например, если добавляется новая запись, а места на страницах БД для этого нет, то создается новая страница, запись размещается на ней, затем ссылка на страницу добавляется в Pointer pages таблицы, после чего в соответствующую inventory pages для новой страницы заносится флаг «занято».Если все это попадает в кэш ОС, то страница inventory pages может попасть на диск раньше новой страницы с записью, в результате чего при reset окажется, что страница как бы занята, и таблица ссылается на нее, а на деле в этой странице …