|
Введение. Данный документ - краткая инструкция по использованию в DELPHI прямых обращений к ядру CУБД Btrieve, написанная для людей с SQL-мышлением, которым судьба-индейка подсунула свинью в виде производственной необходимости временно (или, не дай Создатель, постоянно) использовать это чудо Pervasive-вской мысли. Мне самому пришлось долго и больно перестраиваться с незамутненных SQL-понятий работы с данными на суровую логику программирования более низкого уровня. Данная шпаргалка призвана облегчить этот процесс, и содержит параллели между основными SQL-командами (select/insert/update/delete) и вызовами функции BTRVID, описанной по принципу "черного ящика". Сразу скажу, что не являюсь специалистом по Btrievу (т.е. могу путаться в Btrievовских терминах), большая часть информации получена эмпирическим путем, все примеры использовались в жизни, отлажены и работают.
Отдельно замечу следующее. Вообще говоря, в природе существует Pervasive ODBC, его заменитель Titan Btrieve, и, возможно, кое-что еще, что позволяет обращаться к Btrieve-данным через SQL-запросы. Однако во-первых, это дело работает на порядок медленнее, а во-вторых, в определенных ситуациях (например в моей - мне пришлось организовывать перекачку данных из Informix SQL-сервера в программу "Парус", использующую Btrieve. С Informixом, сами понимаете, никаких проблем не было) из-за специфического формата данных, определяемого конкретным программным продуктом, использование ODBC порой оказывается в принципе невозможным. Например, его (ODBC) приводят в смятение нулевые байты в текстовых полях. И последнее. По правильному, для работы с Btrievом нужно устанавливать Btrievовский Engine, пытаться добиться от него стабильной работы, поганить реестр и все такое. (Может, конечно, это со мной что-то не так, но мне пришлось через это пройти. Хотя на моей работе тратить дни на то, чтобы заставить продукт проявить заявленные возможности считается непозволительной роскошью). Вообще говоря, можно ограничиться набором DLL-библиотек из Pervasive.SQL 2000 Workgroup Engine, которые достаточно переписать в директорию с приложением, или в директорию, прописанную в путях, чтобы можно было работать с Btrievом. Ну - удачи! Необходимое окружение. Прежде всего в директорию, содержащую исходники Delphi-приложения, нужно поместить вышеупомянутые DLL и файлы Btrapi32.pas и BtrConst.pas из Pervasive SDK 2000 и в uses прописать BtrConst и BtrApi32. Если кому интересно назначение этих файлов, может посмотреть сам - там все достаточно прозрачно. Затем в type нужно прописать следующие два типа: CLIENT_ID = packed record
networkandnode : array[1..12] of char;
applicationID : array[1..3] of char;
threadID : smallint;
end;
VERSION_STRUCT = packed record
version : smallint;
revision : smallint;
MKDEId : char;
end;
а в var следующие переменные:
client : CLIENT_ID; {вручную не переинициализировать!}
versionBuffer : array[1..3] of VERSION_STRUCT; {вручную не переинициализировать!}
status : smallint; {вручную не переинициализировать!}
posBlock : string[128]; {вручную не переинициализировать!}
dataBuffer : array[0..255] of char;
keyBuf : string[255];
keyNum : smallint;
dataLen : word;
Физический смысл большинства из этих переменных мне ясен смутно, но он и не важен. Будем считать их частью черного ящика. Переменные, помеченные комментарием {ВРУЧНУЮ НЕ ПЕРЕИНИЦИАЛИЗИРОВАТЬ!} являются системными, Btrieve сам их как-то заполняет и потом с ними работает. Остальные же несут разную смысловую нагрузку в зависимости от действия. Подключение к Btrieve-БД (SQL: Database & Connect в одном флаконе). Чтобы производить любые операции с данными Btrieve, нужно в первую очередь подконнектиться к базе. Чтобы подключиться, нужно выполнить следующий фрагмент кода: fillchar(keyBuf, sizeof(keyBuf), #0);
keybuf := '<Полный путь к любому из *.btr файлов в директории, где лежит БД>' + #0;
fillchar(client.networkAndNode, sizeof(client.networkAndNode), #0);
client.applicationID := 'MT' + #0; {так надо}
сlient.threadID := 50; {так надо}
fillchar(versionBuffer, sizeof(versionBuffer), #0);
dataLen := sizeof(versionBuffer);
status := BTRVID(B_VERSION, {системная константа}
posBlock, {системная}
versionBuffer, {системная}
dataLen, {см.выше}
keyBuf[1], {см.выше}
0,
client); {системная}
if status = B_NO_ERROR значит подконнектилось успешно, иначе - по каким-то причинам не получилось. Причины (из известных) могут быть следующие - приложение не нашло необходимые DLL-ки, неправильно указан путь в keybuf, кривой btr-файл. Подробно ошибки описаны в Pervasive SDK 2000 хэлпах. Отключение от Btrieve-БД (SQL: Disconnect & Close database).
dataLenHead := 0;
status := BTRVID( B_STOP, {системная константа}
posBlock, {системная}
DataBuffer, {см.выше}
dataLen, {см.выше}
keyBuf[1], {см.выше - предыдущий раздел}
0, {}
client ); {системная}
Желательно в конце работы это делать. Во избежание. Открытие таблицы(SQL: Аналог отсутствует). Для выполнения любой операции с таблицей (select/insert/update/delete) необходимо сначала ее открыть. Следующий фрагмент открывает одну отдельно взятую таблицу: fillchar(keyBuf, sizeof(keyBuf), #0);
keybuf := '<Полный путь к *.btr файлу, где лежит таблица>' + #0;
fillchar(dataBuffer, sizeof(dataBuffer), #0);
dataLen := 0;
status := BTRVID(B_OPEN, {системная константа}
PosBlock, {системная}
dataBuffer, {см.выше}
dataLen, {см.выше}
keyBuf[1], {см.выше}
0,
client) {системная}
Если status != B_NO_ERROR, значит, что-то не сложилось. Или файл кривой, или путь неправильный, или с ним уже кто-то работает, или таблица уже открыта, или см. ошибки. Вообще говоря, можно открывать сразу несколько таблиц, и одновременно с ними работать. Но в этом случае для корректной работы нужно для каждой таблицы завести свой набор переменных posBlock,
dataBuffer,
keyBuf,
keyNum,
dataLen
Наверное, можно даже применить массивы.
Закрытие таблицы(SQL: Аналог отсутствует). Все то же самое, как в открытии таблицы. Единственное отличие - B_CLOSE вместо B_OPEN. Для вящей корректности после окончания работ с таблицей нужно ее закрыть. Добавление записи(SQL: INSERT). Для работы с конкретной таблицей необходимо: 1) Чтобы на эту таблицу было наложено заклинание эксклюзивного доступа... (Sorry, пиво...) Продолжаю на трезвую голову. Так вот: для работы с таблицей на самом деле необходимо следующее-
1) Должна быть описана структура таблицы. Например (таблица хозяйственных операций "Паруса"):
type
OPERHEAD_STRUCT = packed record
ISN : integer;
opDate : array[0..8] of char;
agnFrom : array[0..15] of char;
agnTo : array[0..15] of char;
docType : array[0..5] of char;
docNumb : array[0..12] of char;
docDate : array[0..8] of char;
basType : array[0..5] of char;
basNumb : array[0..12] of char;
basDate : array[0..8] of char; {см. ссылку в тексте}
resSum : double;
spMark : array[0..5] of char;
opCont : array[0..80] of char;
invSign : smallint;
subAgn : array[0..15] of char;
appName : array[0..8] of char;
appIsn : longint;
resMSum : double; {см. ссылку в тексте}
sysNumb : array[0..3] of char;
regNumb : longint;
opMngCnt : array[0..80] of char;
end;
var
OperheadRecord : OPERHEAD_STRUCT;
Важно! Для корректной работы должен быть соблюден размер полей в байтах. Через Database Explorer можно посмотреть структуру Btrieve-таблицы, с которой нужно работать. Там мы увидим, что поле resMSum, например, типа FLOAT и размером 8 байт. Этим размером и свойствами в Delphi обладает тип double. Поля типа CHAR в Btrieve имеют две характеристики - логическую длину и физическую (на байт больше). Это также видно в DBE. Поле basDate, например, логически длиной 9 байт, а физически - 10. Нужно исходить из логической длины, и поля типа CHAR описывать как начинающиеся с нуля массивы of char. Поле basDate в этом случае представляется как массив 0..8, т.е. 9 байт. 2) Данная запись должна быть проинициализирована. Вообще Btrieve все аналоги SQL-операций может выполнять только с записью целиком. Поэтому перед каждым "INSERT"ом или "UPDATE"ом нужно, чтобы все поля записи были заполнены нужным образом. Специфика заполнения такова: а) Текстовые поля:
StrPCopy(OperheadRecord.agnto, AsString со значением + #0);
{ собственно присвоение значения }
CharToOem(OperheadRecord.agnto,OperheadRecord.agnto);
{ конвертация - если необходимо. CharToOem всего лишь одна из набора }
{ конвертационных функций из MustDie SDK }
б) Числовые поля:
OperheadRecord.resmsum := AsFloat со значением;
Здесь главное - совместимость типов. Достаточно легко определяется.
в) Автоинкременты:
fillchar(OperheadRecord.isn , SizeOf(OperheadRecord.isn), #0);
Независимо от типа. Просто заполняем их нулевыми байтами, Btrieve сам присвоит нужное значене.
3) Собственно INSERT :
dataLen := sizeof(OPERHEAD_STRUCT);
status := BTRVID(B_INSERT, {системная константа}
PosBlock, {системная}
OperheadRecord, {собственно запись - см.выше}
dataLen, {см.выше}
keyBuf, {путь к таблице - см.выше}
-1,
client) ; {системная}
Статус, понятно, должен оказаться равен B_NO_ERROR.
Позиционирование/Поиск(SQL: SELECT & FETCH в одном флаконе). Я для работы обошелся всего тремя опциями - B_GET_EQUAL, B_GET_FIRST, B_GET_NEXT. Вообще их там больше. Но поскольку даже в совокупности они все равно не заменят всю прелесть SQL, лучше потратить силы не на изучение всяких нюансов сомнительной ценности, а на то, чтобы избежать использования Btrieve в принципе :-). Для начала - общая информация. B_GET_EQUAL предназначен для выборки одной записи из таблицы. Если результатом запроса будет выборка из более чем одной записи, он вернет первую и на этом успокоится. B_GET_FIRST инициализирует выборку из более чем одной записи, и возвращает первую из выборки (скажу сразу - сортировка мне была не нужна, насчет нее ничего не знаю.). Если дальше мы будем выполнять B_GET_NEXT, то за каждое выполнение будем получать по одной следующей записи из выборки. Причем если упрется в конец файла, то выдаст status с кодом 9. В противном случае похоже, что просто пойдет дальше по файлу, несмотря на то, что начиная с какой-то записи все последующие уже не будут отвечать условиям выборки. Скажу сразу, что здесь я не уверен до конца в своих знаниях, могу ошибаться. Короче, у меня в программе в WHILE с GET_NEXTами стоит проверка сразу двух условий - чтобы status был B_NO_ERROR и чтобы полученные значения условиям выборки отвечали. Хотя бы одно не выполнилось - из WHILE выхожу. Пока работает. И последнее. Все эти GETы могут искать только по полям, описанным в индексах таблицы. Свое мнение об этом деликатно опускаю. Теперь - собственно описание синтаксиса. Для того, чтобы выполнить B_GET_EQUAL, нужно: а) Описать структуру индексов. Например, в уже упомянутой таблице OPERHEAD есть следующие индексы:
type
OPERHEAD_INDEX7 = packed record
appIsn : longint;
appName : array[0..8] of char;
end;
OPERHEAD_INDEX0 = packed record
ISN : integer;
end;
var
OperHeadIndex0 : OPERHEAD_INDEX0; {индекс номер 0}
OperHeadIndex7 : OPERHEAD_INDEX7; {индекс номер 7}
Информацию об индексаx можно посмотреть в том же DBE.
б) Далее - код:
OperheadIndex0.isn := значение AsInteger; {присвоение параметров поиска}
fillchar(OperheadRecord , SizeOf(OperheadRecord), #0);
dataLen := sizeof(OPERHEAD_STRUCT);
status := BTRVID(B_GET_EQUAL, {системная константа}
PosBlock, {системная}
OperheadRecord, {сюда будет возвращен результат поиска}
dataLen, {см.выше}
OperheadIndex0, {см.выше}
0, {номер индеска - см.выше}
client); {системная}
Если status <> B_NO_ERROR and <> B_KEY_VALUE_NOT_FOUND - значит, чего-то нашлось.
Использование других GETов осуществляется по этой же схеме. Единственная разница - вместо B_GET_EQUAL нужно поставить B_GET_FIRST или B_GET_NEXT. Важно! B_GET_EQUAL может использовать только уникальные индексы! B_GET_FIRST и B_GET_NEXT - любые. Обновление записи(SQL: UPDATE). Самое главное - здесь рассмотрен вариант обновления одной записи. У меня сложилось впечатление, что вообще в Btrieve можно обновлять и удалять только по одной записи, но поскольку у меня не хватило терпения изучить HELP до конца, наверняка утверждать не могу. Итак: Непосредственно перед действием обновления у нас должен быть выполнен B_GET_EQUAL, который спозиционирует указатель в таблице именно на ту запись, которую мы будем апдейтить. ( У меня есть подозрение, что информация о позиционировании хранится в PosBlockе. Впрочем, какая разница?) Далее мы должны полностью заполнить запись таблицы (в нашем случае - OperheadRecord). Вообще говоря, поскольку только что выполнился B_GET_EQUAL, OperheadRecord у нас уже заполнен. Мы можем просто переприсвоить те поля, какие хотим изменить. Специфику заполнения см. в разделе, посвященном INSERTу. Далее - код: dataLen := SizeOf(OPERHEAD_STRUCT);
status := BTRVID(B_UPDATE, {системная константа}
posBlock, {системная}
OperheadRecord, {см.выше}
dataLen, {см.выше}
keyBuf, {путь к таблице - см.выше}
-1,
client) {системная}
Status, сами понимаете, должен оказаться B_NO_ERROR. Если все в порядке.
Удаление записи(SQL: DELETE). Использование практически совпадает с B_UPDATE. В смысле, сначала должен быть B_GET_EQUAL и все такое. Фрагмент кода немного отличается - B_DELETE вместо B_UPDATE, и DataBuffer вместо OperheadRecord - какой смысл передавать данные, если запись сейчас будет удалена? fillchar(dataBuffer, sizeof(dataBuffer), #0);
dataLen := SizeOf(OPERHEAD_STRUCT);
Status := BTRVID(B_DELETE, {системная константа}
PosBlock, {системная}
DataBuffer, {см.выше}
dataLen, {см.выше}
KeyBuf, {путь к таблице - см.выше}
-1,
client) {системная}
Про status уже и не говорю.
Заключение. Вот, собственно и все, что мне известно. В принципе, в разрозненном виде это все есть и в Pervasive SDK 2000 Help, и в Инете, но мне, например, понадобилось две недели, чтобы вычленить именно эту информацию, абстрагироваться от ненужной, и c прискорбием убедиться в несостоятельности обычного Pervasive ODBC. Может, данный документ кому-то сэкономит время. Хотя лучше всего, если эта информация вам не понадобится вовсе! |
