база данных для мобильного приложения android

Sqlite в Android Studio: база данных

Статья в доступной для восприятия форме рассказывает о практическом применении SQLite Android Studio. В статье описаны основные преимущества программной среды разработки, в краткой форме рассмотрен структурный состав методов и классов.

Операционная система Android с каждым годом завоевывает мир программистов. Вопросом о том, что такое Android Studio, задаются как начинающие, так и опытные разработчики программного обеспечения, знакомые с инструментарием среды управления базами данных SQlite Android studio.

Запускаем SQLite на эмуляторе

Эмулятор Android – один из главных инструментов современного разработчика. Он дает возможность создавать и тестировать работу исходного кода и таблиц в SQl Android Studio без задействования штатных мобильных устройств.

Перед первым запуском база данных в Андроид Студио требует обновления SDK Tools до крайней на текущий момент версии.

С четвертой версии Android и выше в эмуляторе появилась возможность визуальной навигации по панели настроек. А Android Studio база данных может быть расположена на произвольном логическом разделе дискового пространства.

Панель навигации может быть не видна при работе на устройствах с малым разрешением экрана. Чтобы устранить недостаток и вывести панель на экран, требуется активировать пиктограмму «Display a skin with hardware controls».

В штатной командной строке операционной системы компьютера запустить на исполнение программу adb.exe. После начала работы софта необходимо исполнить запуск программной оболочки Shell.

Пиктограмма решетки «#» означает приглашение системы к вводу дополнительных команд.

Далее необходимо определить место, где будет непосредственно храниться информация. Например, если исходный пакет с наименованием «su.aivanushkadur.sample», то полный путь к размещенной базе данных будет выглядеть как «data/data/su.aivanushkadur.sample/databases».

Последней командой для запуска базы данных на эмуляторе будет «cd data/data/su. aivanushkadur.sample/databases/ls/user_db».

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

Классы для работы с SQLite

Начиная с конца 2017 года, прямая работа с приложением считается несколько нерациональным подходом к структуре таблиц.

Суть управления базой сводится к выполнению ряда условий:

Класс ContentValues

Класс ContentValues отвечает за работу с таблицами базы данных и добавление в них вновь созданных строк.

Каждый созданный объект в классе «ContentValues» – это одна строка в виде массива, содержащего данные о столбцах таблицы и информационных блоках, соответствующих столбцам.

Курсоры

Курсоры являются еще одним классом в Android, они отражают перечень запросов к базе данных. Классы «Cursor» выдают результирующую ссылку на адрес хранения исходной информации. Такой подход намного продуктивней альтернативного – извлечение текущей информации из базы и возврат копии запроса.

Классы типа «Cursor» работают со строками или позициями в текущем времени по отношению к общему набору запрашиваемых данных.

Класс SQLite Open Helper: создание базы данных

«SQLite Open Helper» – первичный класс при работе с данными в среде операционной системы Android. Главная функция класса состоит в предоставлении возможности пользователю создавать, удалять и обновлять уже созданные базы.

В составе базового класса включены несколько методов абстрактного вхождения:

Кроме пары главных методов, существует ряд вспомогательных, использующихся по мере необходимости:

В случае если возникла необходимость в создании собственного класса с индивидуальным функционалом, он наследуется от класса «SQLite Open Helper». В структурных подразделах описывается логика и базовый функционал будущего класса.

Аналогичным образом класс влияет на создание стоковых столбцов, адресация которых учитывается при клиентском запросе к базе данных.

К примеру, на основе использования метода «onCreate()» возможно отработать запрос на ликвидацию существующей таблицы. В дальнейшем вновь самостоятельно создать структуру, используя базовый функционал класса «onCreate()». При этом параметры метода анализируют и запоминают две версии таблиц: удаленную и вновь созданную, что упрощает дальнейшую работу по запросам с базой.

SQLiteDatabase

Класс «SQLiteDatabase» – основа управления данными интерфейса. Базовый набор класса «SQLiteDatabase» штатно включает в себя методы:

Рабочий функционал методов, входящих в состав класса, ограничен базовым набором управления. Доступно только создание, удаление, внесение изменений и чтение информационной составляющей. Отдельно стоит упомянуть о решении, позволяющем подстраивать код любой структуры на исполнение в среде языка SQL.

Метод query()

Метод «query()» в большинстве случаев используется для выполнения операций чтения данных из общей базы.

Составляющие метода делятся семь условных параметров, вызываемых в процессе запросов или отражаемых командой «null». В число параметров входят:

Метод rawQuery()

Метод используется нечасто из-за редкого использования пустых запросов к SQL базе. Основан на прямом написании командной строки, вида аналогичного прямому написанию в среде SQL.

Метод insert()

Метод имеет перспективу частого применения, необходим при вставке данных в таблицы SQLite, в своем составе имеет три параметра:

Метод update()

Суть работы метода исходит из его названия – обновление существующих и вновь созданных (загруженных) данных. Для корректной работы необходимо задать методу параметры таблицы базы данных, требующей обновления.

Метод delete()

Работает по принципу аналогичному методу «update()», за исключением конечного результата выполнения. При заявленных параметрах местонахождения таблицы базы данных, «delete» удаляет все информационные составляющие.

Требует обязательного отражения оператора «WHERE», после выполнения которого на экране визуализируются удаленные строки.

Метод open Or Create Database: Открытие и создание баз данных без использования SQLite Open Helper

Метод дает возможность с легкостью редактировать созданные базы данных и создавать необходимые, используя информативный объект «Context».

Доступность базы данных при использовании метода включает буквально пару шагов:

Контент-провайдеры

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

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

Вставляем картинки в базу

База данных SQLite не имеет прямого функционала взаимодействия с форматами изображений, из чего вытекает единственный метод решения проблемы – двухсторонняя конвертация изображения в массив байтового уровня.

Обратная конвертация массива в формат изображения при извлечении картинки выполняется реверсивно.

Тематическое видео с наглядным пояснением работы доступно по ссылке.

Источник

Превращение Android телефона в сетевую SQL базу данных (MyMobileSQLServer — Utesov)

Недавно я начал делать очередной проект для мобильных устройств. Его побочным продуктом стало приложение, с помощью которого можно развернуть сетевую базу данных на любимом Android телефоне, планшете и т.п… Предлагаемое решение является сетевым провайдером SQLite базы данных.

Приложение многопользовательское, каждый пользователь имеет свою БД, которая недоступна другим пользователям. Код открытый, лицензия Apache 2.0.

Для демонстрации заявленных возможностей написано простое приложение которое позволяет делать SQL запросы на сервер и получать результаты их выполнения, его код рассмотрим здесь. Время освоения — 10 минут. Для тестирования достаточно одного устройства (если используется два и более, то необходимо WiFi подключение). Поехали!

Перейдем к непосредственному созданию приложения для доступа к сетевой БД.

1 — Создаем новый проект. Копируем файл библиотеки «myMobileSQLClient.jar» в директорию для хранения библиотек и делаем необходимые действия, чтобы она стала доступна для проекта

2 — Настраиваем манифест проекта, добавляем директиву для возможности использования подключения к сети:

3 — Кидаем на форму:
пять полей ввода: IP адрес, номер порта, текст для sql запроса, логин, пароль;
три кнопки: подключиться, отключиться, отправить запрос;
поле для вывода информации.
У вас должно получиться примерно так:

Копируем следующий код с необходимыми корректировками:

Теперь разберемся что происходит.
За работу с удаленной БД отвечает данный объект:
MainMobileSQLClient mainMobileSQLClient;
В нём переопределены следующие методы:
onMessage — пришло сообщение с сервера;
onConnection — клиент осуществляет подключение к серверу;
onConnect — клиент подсоединился к серверу;
onDisconnect — клиент отсоединился от сервера;
onErrAuthentication — ошибка аутентификации;
onCompleteAuthentication — аутентификация прошла успешно;

При создании главного объекта задается IP адрес сервера и порт для подключения. Запуск клиента осуществляется с помощью метода startClient(). Начало подключения сопровождается методом onConnection. Если произошла ошибка подключения, то вызывается метод onDisconnect, который также вызывается при отключении клиента от сервера (например при разрыве соединения или отключении сервера). Если всё произошло в штатном режиме, то завершение процесса подключения ознаменует метод onConnect.

Далее необходимо произвести регистрацию пользователя на сервере, лучше всего делать это после окончания подключения, прямо в методе onConnect:

В случае успеха аутентификации, будет вызван метод onCompleteAuthentication, иначе onErrAuthentication. Если аутентификация не произошла, то скорее всего ваши логин и пароль не совпадают с теми, которые были зарегистрированы на сервере.

Теперь дело остается за малым — делать запросы и обрабатывать реакцию на приходящие данные.
Чтобы инициировать SQL запрос, необходимо вызвать метод (пример):
String id_request = mainMobileSQLClient.sendSQLRequest(»select * from test;»);
Он, в свою очередь, возвратит идентификатор запроса в виде текстовой строки. Это важно, так как это сетевое приложение, оно работает асинхронно. Когда с сервера приходит новый ответ, то вызывается метод onMessage(String id, DATA_parser data), который передает идентификатор запроса (id), на который пришел ответ и сами данные (data). Данные предоставляются в виде объекта DATA_request, в котором имеются следующие объекты:
status — String — статус результата запроса данных, если «ok», то запрос отработан удачно, иначе «err» (в дальнейшем статусы возможно будут пополняться);
recordsCount — int— количество записей пришедших от сервера, являющиеся результатом запроса;
structure — String[] — текстовый массив, являющийся перечислением названий всех полей ответного запроса;
listData — ArrayList — список массивов данных. Количество элементов в списке соответствует количеству записей с сервера. В каждом элементе находится текстовый массив, с количеством элементов равным количеству элементов в массиве structure.

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

Всё готово! Теперь приступайте к тестированию, отправляйте любые SQL запросы на сервер (создание таблиц, вставка/модификация данных, удаление записей и т.д.) и получайте соответствующие результаты выполнения.

Репозиторий с сервером, клиентом, библиотекой и примером приложения — https://github.com/gc986/MyMobileSQLServer_Utesov
(В настоящее время в репозитории находится самая первая версия проекта подготовленная в формате ADT Eclipse. Следующим этапом станет перевод проекта под формат AndroidStudio)

Вопрос к хабраудитории: где можно применить данное решение?

Источник

Работа с СУБД SQLite под Android

В основе многих приложений лежат те или иные базы данных (БД). Мобильные приложения для Android не исключение.

В Android присутствует поддержка СУБД SQLite поэтому приложения на основе БД для этой ОС чаще всего используют именно её. Разумеется, что если не все, то большинство средств разработки для Android, включая Delphi, также имеют встроенную поддержку этой СУБД.

Создание приложения на основе СУБД SQLite

Рассмотрим пример создания приложения на основе СУБД SQLite.

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

Для доступа к БД воспользуемся компонентами FireDAC. Поместим на форму компоненты FDConnection, FDQuery и FDGUIxWaitCursor.

Настроим FDConnection для доступа к БД. Для этого установим следующие значения свойств

В свойстве SQL компонента FDQuery напишем простейший запрос.

Этого достаточно для получения данных из БД. Однако эти данные необходимо как-то отображать.

В отличие от VCL в FireMonkey отсутствуют специализированные компоненты для отображения данных из БД (на подобие DBGrid и т.д.). Поэтому для этих целей приходится использовать обычные компоненты и связывать их с БД посредством LiveBindings. Точнее, компонента BindSourceDB.

Для того чтобы отобразить данные из БД воспользуемся компонентом StringGrid.

Поместим на форму компонент BindSourceDB и установим в качестве DataSet компонент FDQuery.

Установим свойство Connected компонента FDConnection и свойство Active компонента FDQuery в значение true. Далее, щёлкнув правой кнопкой мыши на компоненте BindSourceDB, выберем в контекстном меню пункт «Bind Visually…». Откроется визуальный редактор связей LiveBindings (см. скриншот ниже).

LiveBindings позволяет связать с компонентом набор данных, как целиком, так и по отдельности (отдельные поля). Чтобы в StringGrid отображались все поля, свяжем его с набором данных целиком как показано на скриншоте.

Доработка созданного приложения для работы под Android

Созданное выше приложение вполне работоспособно и его можно спокойно запустить на выполнение в среде Windows. Но, если попытаться запустить это же приложение под Android, то ничего не получится. Причина в особенностях этой ОС. Поэтому, перед запуском приложения под Android, его необходимо предварительно подготовить.

Первое, что нужно сделать, это включить файл БД в состав проекта. Тогда файл БД при компиляции будет автоматически включен в состав файла приложения (apk).

После того как файл БД добавлен нужно сделать так, чтобы приложение при запуске могло его найти в файловой системе Android.

В данном случае файл БД будет расположен в папке assets\internal\.

Определив расположение файла БД можно прописать путь к нему. Лучше всего это сделать программно в обработчике события BeforeConnection компонента FDConnection, как показано ниже.

Источник

Подключиться мобильным устройством к базе данных без написания серверного кода

Привет, Хабр! Хочу поделиться своим опытом использования Форсайт мобильной платформы.

Если у вас встанет задача удалённого хранения данных и при этом не писать собственный сервер, то первое, что придёт на ум это инструмент Firebase Realtime Database. Большинство читающих знают, о чём идёт речь, но для остальных поясню. С помощью Firebase Database можно хранить удаленно данные в NoSql-ом виде.

Картинка с сайта firebase

Из плюсов использования:

ФМП + PostgreSQL

Теперь хочу вам рассказать про альтернативный инструмент, которым мне приходится пользоваться.

Зайду издалека. Где-то у меня имеется поднятый сервер PostreSQL с базой данных. В базе данных у меня есть таблица с фруктами:

Что такое PostreSQL как с ним работать можно почитать тут.

Моя задача, чтобы эта таблица как можно быстрее оказалась на телефоне с наименьшим написанием кода и обеспечения безопасности на каждом этапе.

Вот таблица my_table_fruits в pgAdmin4:

Далее нахожу в дереве pgAdmin4 процедуры. Пишу собственную процедуру на получение таблицы:

Процедура будет иметь название fruits_get_by_color и будет отдавать мне фрукты определённого цвета из моей таблицы my_table_fruits.

После этого перехожу на сервер Форсайт мобильной платформы (далее ФМП). Как развернуть платформу и что для этого нужно можно прочитать в документации. ФМП представляет собой сервер, который имеет коннекторы к серверам баз данных. Может приконнектиться и к нужному нам PostgreSQL. Код писать для этого никакой не нужно. С чем мне приходится работать, так это с панелью администратора через браузер. Вводить необходимые адреса серверов, баз данных. Панель администратора имеет настройки и дерево сред:

Более подробно про настройки также можно прочитать в документации.

К сожалению, никаких пробных версий или бесплатных периодов у ФМП нету. Также ФМП разворачивают в защищенной инфраструктуре заказчика. Поэтому ссылок на сервер, чтобы попробовать, не смогу предоставить. Но, чтобы понять суть работы, нижеследующей информации вполне хватит.

Создаю новую среду в дереве сред, например назову её Leonid_environment. Внутри среды создаю проект, например Leonid_project. Захожу в проект и создаю там источник данных, в нашем случае PostgreSQL. Ввожу параметры сервера и базы данных, в которой храниться моя таблица:

Захожу внутрь источника данных и жму “Импортировать”. Ввожу в название источника наименование той процедуры, которую ввёл в PostgreSQL, в данном случае fruits_get_by_color. Для мобильного клиента можно придумать другое название, хотя не обязательно. Назову его fruits_get_by_color_for_android:

После нажатия кнопки “Импортировать”, платформа ФМП “увидит” нашу процедуру и параметры, которые мы должны туда передать.

В частности, она увидит, что мы должны передать параметр fruit_color:

После этого необходимо перейти во вкладку “Пользователи API” и создать пользователя. Создал пользователя с логином Leonid и паролем 123123:

Начиная с этого момента можно переходить в Android Studio, чтобы получить эти данные на мобильный телефон.

ФМП + android

Создаю новый проект. Вместе с платформой распространяется фреймворк для работы с ней. Подтягиваю фреймворк в проект File → import module → *.aar

В проекте объявляю ряд констант, в которые вставляю адрес сервера, а также придуманные мной название среды, название проекта, логин, пароль, наименование ресурса из ФМП:

Обратите внимание, что обращаемся именно к ФМП, а не напрямую к PostgreSQL. Далее необходимо создать объект HyperHive и засетить объявленные переменные:

Затем нужно выполнить авторизацию. Для этого передаём логин и пароль в метод auth():

При получении true можно запрашивать содержимое таблицы, что и сделаем. В объект tableStreamCallParams передадим в виде json-а параметр fruit_color и введём для него значение yellow. Напомню, что мы создавали таблицу фруктов и создавали в PostreSQL процедуру, которая принимает на вход параметр цвета. Это нужно было, чтобы на устройстве ввести данный параметр:

После запроса мы обращаемся к серверу ФМП. Сервер ФМП обращается к серверу PostgreSQL. В итоге мы должны получить список желтых фруктов:

Строки stream-ятся в базу SQLite. В данном случае цвета yellow были только banana и lemon. Скорость загрузки закешированных на стороне ФМП данных примерно 10000 строк в секунду при нормальной скорости интернета.

Все описанные мною шаги можно прочесть в документации. Также там есть информация про подключение к iOs и другим операционным системам.

Сделал запрос из основного потока и не обработал ошибки, чтобы сократить количество кода.

Функционал ФМП

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

Пройдусь широкими шагами по основному функционалу ФМП:

Плюсы и минусы ФМП

Приведу плюсы и минусы, которые вижу со своей точки зрения. В зависимости от специфики и размера проекта, думаю, вы будете не со всем согласны.

Выводы

Сравнение платформы ФМП с Firebase Realtime Database было “притянуто за уши”, т.к. хотелось хоть с чем-то сравнить знакомым android- и iOs-разработчику. На самом деле ФМП имеет несколько другой функционал и цели. Среди конкурентов можно привести SAP Mobile Platform, IBM first mobile platform, Оптимум CDC.

В заключение хочу сказать, что на ФМП стоит обратить внимание, если у вас есть:

Источник

Выбор СУБД для мобильного Delphi-приложения

Данная статья написана по мотивам – мотивам разработки мобильного приложения, недавно вышедшего на платформах iOS и Android. Это событие можно было бы назвать заурядным и мало кому интересным, если бы не одно большое и несколько незначительных «но»: вся разработка (включая сервер) велась на Delphi, а в качестве СУБД, как ни странно, задействована совсем не SQLite. Автор, безусловно, понимает, что на текущий момент уже существуют мобильные Delphi-приложения, включая доступные в официальных магазинах, однако не наблюдает обилия русскоязычных публикаций, призванных, как минимум, предостеречь читателей от ошибок, сделанных разработчиком таких проектов. Написанное же здесь преследует цель помочь тем, кто сейчас выбирает СУБД для своего творения, либо уже остановился на каком-то варианте, но желает убедиться в правильности своего решения.

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

Меж двух огней

Безусловным лидером мобильных СУБД является SQLite, однако некоторые её недостатки и наличие у приложения функционала, требующего нетривиального анализа данных, не позволили остановиться на ней – поиск альтернатив привёл к Interbase XE7, точнее к его встраиваемой (embedded) версии, которая, что удобно, сразу поставляется с Delphi и требует минимума усилий по включению в состав приложения. Interbase, конечно же, идеалом тоже не является и обладает минусами, способы борьбы с которыми приводятся ниже. Важно отметить, что эта СУБД коммерческая, поэтому предлагаются две редакции: IBLite – бесплатная, именно о ней будет идти речь, и Interbase ToGo – платная, но с такой ценовой политикой, что полностью исключает её использование в бесплатных приложениях; ограничения IBLite суровы, но будут показаны способы существования и с ними (в связке с FireDAC).

Основное преимущество Interbase

Итак, начнём обоснование выбора СУБД с ключевой возможности проекта – рекомендаций по наполнению списков товарами. Суть действа в следующем: представьте, что в позапрошлые выходные Вы добавляли в списки такие товары, как зубная паста, апельсины и говядина, а в прошлые – свинину, снова апельсины и ириску. С немалой степенью вероятности можно утверждать, что в эти субботу и воскресенье новый список необходимо наполнить апельсинами и мясом (именно в таком обобщённом виде, т. к. о конкретном виде мяса ничего сказать нельзя). Собственно эти два продукта и будут предложены пользователю. Пример с закономерностью в выходные – это лишь один из вариантов, бывают товары, добавляемые каждый день, через день, в начале месяца и т. д. – всего приложение анализирует 21 случай, что, вкупе с необходимостью обобщения, делает объём вычислений весьма приличным.

На устройстве рекомендации выглядят примерно так:

Подобные расчёты оптимальнее всего выполнять полностью на стороне СУБД, ибо накладные расходы на копирование данных из БД в структуры приложения, а также сложность и, как следствие, подверженность ошибкам алгоритмов обработки этих структур, могут довести время ожидания до десятков секунд, что неприемлемо. Решение – хранимые процедуры (далее ХП), которые присутствуют только в Interbase.

Другим серьёзным доводом за ХП являются требования фонового выполнения операции (без блокировки интерфейса), а также её досрочной отмены – ведь речь о длительностях в несколько секунд. В случае SQLite сложность решения такой задачи много больше, т. к. требуется вынести все многочисленные запросы к БД и обработку их результатов в отдельный поток и самостоятельно реагировать на флаг отмены. Вызов же одной ХП в FireDAC можно сделать асинхронным, что автоматически решает поставленные задачи:

Три довода в пользу SQLite

После немаленькой ложки мёда из процедур, перейдём к такой же большой ложке дёгтя из отсутствия некоторых возможностей в Interbase. Горечь будет идти по нарастающей, чтобы сразу не шокировать читателя некоторыми, так скажем, особенностями этой СУБД.

Выше говорилось о требовании обобщать товары при выдаче рекомендаций, что реализовано, в том числе, за счёт иерархического справочника товаров. Так вот SQLite имеет средства для ускорения работы с деревьями за счёт обобщённых табличных выражений (CTE) вида

а соперник – нет, предлагая решать такие задачи через рекурсивные ХП.

Примечание. Написанное справедливо на момент публикации статьи, однако в вышедший недавно Interbase 2017 добавлена частичная поддержка CTE — без рекурсивной части, которая обещана позднее.

Полнотекстовый поиск

Следующий неприятный сюрприз связан с индексированным поиском по строковым полям. При добавлении нового товара, приложение предлагает пользователю варианты, основанные на уже введённых символах:

SQLite на такой случай даёт очень мощный (даже избыточный для этого примера) механизм полнотекстового поиска, обладающий заведомо высокой скоростью работы; Interbase же задействует индекс только при поиске по началу строки, тогда как требуется искать совпадение с любой позиции. Другими словами, это условие будет использовать индекс

а применяемое в приложении уже нет

На небольшом наборе данных проблема слабо проявляет себя – текущий справочник товаров содержит 700 записей, безындексный перебор которых на iPhone 5c занимает, в худшем случае, 240 мс, что заметно при наборе, но ещё находится в зоне комфорта.

Производные таблицы

Самым горьким, даже ошарашивающим недостатком Interbase (особенно учитывая какой сегодня год) стала невозможность применять производные (derived) таблицы:

Вместо этого необходимо создавать представление (что предпочтительнее варианта далее, потому что оно может быть «развёрнуто» оптимизатором) и выполнять соединение с ним

либо применять ХП, изменив тип соединения

Левое внешнее соединение приходится задействовать из-за одной застарелой проблемы, которая может проявиться при выполнении такого кода: при внутреннем соединении ( JOIN ) СУБД не учитывает зависимость вызова процедуры от полей таблицы, в результате значения для параметров ХП не могут быть определены из-за ещё непрочитанных записей таблицы.

Примечание. Написанное справедливо на момент публикации статьи, однако в вышедший недавно Interbase 2017 добавлена поддержка производных таблиц.

Работа с данными в потоке

Вторая важная функция приложения – синхронизация списков между устройствами.

Проблема нестабильного курсора

Способов борьбы два: первый заключается в добавлении искусственной сортировки в цикл

а второй – в использовании временной таблицы

Защита БД

Самым надёжным способом защитить структуру базы и её данные можно назвать шифрование; оно имеется в SQLite, но беспощадно вырезано из бесплатного IBLite. Хорошей новостью будет то, что имеется другой механизм, позволяющий блокировать подключение к БД любопытствующим, не знающим пароль, причём он действует и в случае копирования БД на машину, где установлен сервер Interbase с полным административным доступом, – способ заключается во включении Embedded User Authentication (EUA) для нужной базы данных. Если БД только создаётся, то код будет выглядеть так:

В противном случае применяется команда

Переход на EUA, кроме всего прочего, даёт возможность исключить файл admin.ib из состава приложения, сэкономив почти 500 Кб:

После задействования EUA, рекомендуется повысить надёжность хранения пароля (одновременно увеличив ограничение на его длину с 8 до 32 байт):

Последним рубежом обороны – в случае извлечения пароля из исполняемого файла или ручной правки самой базы данных, может стать удаление исходного кода ХП, триггеров и представлений при помощи скрипта, модифицирующего системные таблицы:

где строки ‘TR_’ и ‘VW_’ необходимо заменить на Ваши шаблоны именования триггеров и представлений соответственно.

Источник