Интернет магазин китайских планшетных компьютеров

Компьютеры - Btrieve - Версии

Btrieve для DOS

Существовала одна клиентская конфигурация Btrieve для DOS, созданная в SoftCraft. Их фирменное определение понятия «клиентский» звучало так: «Ядро Btrieve, исполняющееся на отдельной рабочей станции». То есть ядро менеджера записей взаимодействовало с файлами данных напрямую, через вызовы операционной системы, и изменяло записи единообразно, вне зависимости от того, находились ли файлы локально или на сетевом ресурсе. Такое «клиентское» ядро позволяло одновременно работать с БД пяти конкурирующим пользователям. Все манипуляции с записями проводились локально, на той рабочей станции, на которой работало ядро СУБД. Btrieve для DOS могла использовать обе стратегии совместного доступа к файлам.

Btrieve для Netware

Btrieve для Netware, по существу, была той же Btrieve для DOS с некоторыми дополнительными возможностями, доступными в то время только на Netware. На файловом сервере запускался процесс BSERVER, и файловый серевер начинал управлять операциями ввода/вывода данных БД, одновременно продолжая предоставлять сетевую файловую систему. Первоначально серверный процесс был реализован как Netware Value Added Process под именем BSERVER.VAP, но вскоре был переделан в NetWare Loadable Module. В основном BSERVER был ядром СУБД, отвечающим за обеспечение доступа к записям, но кроме этого он ещё принимал запросы на передачу данных другим серверам. Эти запросы поступали через отдельный процесс называвшийся BROUTER.

Для передачи запросов ввода/вывода данных из/в БД, на клиентских рабочих станциях использовались т. н. реквесторы, доступные для DOS, OS/2, Microsoft Windows и UnixWare. Программа BREQUEST.EXE принимала запросы через Btrieve API и перенаправляла их сервису BSERVER, а после этого обрабатывала ответ BSERVER и перенаправляла его обратно, соответствующему приложению.

Процесс BROUTER позволял перенаправлять поступающие запросы на другой сервер, содержащий копию БД. Он загружался на сервере Netware и занимался коммуникациями между серверными процессами, запущенными на файловом сервере, руководствуясь при этом двумя FST-таблицами). В соответствии с документаций Pervasive, эти таблицы содержат список имён и адреса серверов, и таблицу маршрутизации серверов SRT). Помимо этого, BROUTER мог перенаправлять коммуникационные запросы на соответствующий сервер по SPX, через BSPXCOM, и занимался координацией блокировок и прочих механизмов, контролирующих доступ к данным в БД.

Btrieve для Netware использовала те же стратеги SEFS и MEFS для совместного доступа к файлам, что и под DOS, но поскольку могла функционировать в сети, то могла поддерживать как эксклюзивные, так и конкурирующие транзакции.

Btrieve для Windows

Btrieve для Windows появилась до того, как компания переписала основной код СУБД с использованием MKDE. В ней использовались SEFS и MEFS механизмы совместного использования файлов, механизм shadow-paging, эксклюзивные и конкурирующие блокировки. Файлы версий 6.x и 6.1 обрабатывались различным образом: в файлах версии 6.x возможно было оперировать фрагментами записей, вместо блокировки всей записи целиком; допускались записи более 64KB; были реализованы variable-tail allocation table, Alternate Collating Sequence и новые типы данных; разрешались долевые операции; разрешались дублирующиеся поисковые ключи. В версии 6.x появилась возможность добавлять и удалять любые индексы «на лету». Файлы версии 6.1 поддерживали конкурентные и системные транзакции; возможность перенумерации ключей; нечувствительные к регистру ACS-таблицы и усовершенствованные операции блокировок.

Btrieve для Windows могла работать как клиент БД использующей SEFS или MEFS режимы, или могла напрямую работать с сервером Btrieve.

Клиентский Btrieve

Для клиентской Btrieve все файлы БД находились либо на локальном компьютере, либо на сетевом диске, подключённом в этому компьютеру.

Приложение выполняло вызовы функций библиотеки WBTRCALL.DLL, являвшейся интерфейсом к загрузчику/реквестору. Модуль загрузчика/реквестора проверял конфигурационный файл BTI.INI на предмет корректной настройки для загрузки клиентского ядра Btrieve, и в свою очередь загружал локальный интерфейс к ядру Btrieve, библиотеку WBTRLOCL.DLL. При необходимости этот локальный интерфейс загружал в оперативную память ядро Btrieve и начинал передавать ему запросы к БД. Для доступа к файлам БД, ядро СУБД пользовалось вызовами разнообразных системных библиотек Win32

Доступ из клиентского Btrieve к серверному

Клиентская версия Btrieve для Windows могла обращаться к серверной через специальный реквестор для DOS. Этот реквестор требовал использования DPMI, который обеспечивал программы доступом к расширенной памяти, доступной только через защищённый режим процессоров x86.

Также как и в случае клиентского интерфейса, Btrieve приложение выполняло вызов к библиотеке WBTRCALL.DLL, которая проверяла BTI.INI, чтобы определить где находится БД, на локальной системе или на удаленном сервере. Если было необходимо работать с удаленным сервером, она использовала Windows версию DPMI для доступа к реквестору BREQUEST.EXE, запущенному под DOS, который уже и устанавливал сетевое соединение с сервером, обрабатывающим запросы к БД и возвращающим ревестору сообщение по завершении их обработки.

Btrieve для Windows NT/Windows 95

Btrieve для Windows NT и Windows 95 была выпущена в 1995 году, вместе с Btrieve для Netware и для Windows NT Server. Номер версии достиг 6.15 и началось использование микроядерной акрхитектуры. Механизмы совместного использования файлов остались те же; использовалось shadow-paging, поддерживались эксклюзивные и конкурирующие блокировки. Эта версия Btrieve разрешала использование null для ключей, что позволяло вносить записи в БД даже если ключевая информация отсутствует. Такие ключи не участвовали в индексировании, что сокращало бесполезный поиск по индексу в БД. В этой же версии была введена концепция системных транзакций и пользовательских транзакций. . MKDE разрешало разрывы между автоинкрементными ключами. Variable-tail allocation tables появились в версии 6.15, таким образом они были включены в сборку Btrieve для Windows NT/95.

Существовало две конфигурации Btrieve для Windows NT/95: standalone workstation и client/server.

Standalone Workstation

При использовании standalone workstation конфигурации Btrieve, вся обработка записей производилась на локальной рабочей станции, полагаясь на локальные механизмы Windows, пользуясь которыми MKDE получало доступа к файлам БД и накладывало файловые блокировки, для синхронизации параллельных операций.

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

Однако такой подход имеет неприятные побочные следствия. Если Btrieve использует сетевой механизм Windows, а ядро СУБД открывает файлы напрямую с сетевого ресурса, и возникает сбой локальной сети, в процессе обновления полей связывающих файлы Btrieve, может наступить рассинхронизация, нарушатся связи между данными, и файлы БД будут испорчены.

Client/Server

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

Под Windows 95, интерфейс MKDE в действительности определяет способ доступа к БД через конфигурационный файл. Если он обнаруживает, что на компьютере установлены оба варианта ядра СУБД, то производится проверка, какой из них предписано использовать. При работе под Windows NT, если одновременно запущены серверный процесс NTMKDE.EXE и процесс от standalone workstation, указание на использование того или другого должно быть сделано в реестре. В обоих случаях, если интерфейсу MKDE указано использовать режим standalone workstation, он будет использовать W32MKDE.EXE для прямого доступа к файлам. Если же указано использовать режим сервера, то MKDE-интерфейс на клиенте будет использовать отдельный коммуникационный модуль который будет взаимодействовать с сервером. Сам сервер имеет свой собственный коммуникационный модуль, находящийся на отображённом сетевом диске. Далее, серверная DLL взаимодействует с серверным MKDE, которое обновляет записи и возвращает клиенту подтверждение об успешном завершении, через тот же коммуникационный модуль.

Переимущества такого подхода в том, что при сбое локальной сети, MKDE на сервере способно обнаружить это и более аккуратно выполнить восстановление, чем в конфигурации standalone workstation.

Конфигурирование

Btrieve включает утилиту для настройки параметров MKDE. Следующие параметры могут быть настроены:

• File settings: в этой категории находятся настройки относящиеся к файлам, дескрипторам файлов, блокировкам записей, индексам и журналированию. Здесь можно установить максимальное количество открытых файлов доступных системе и число блокировок записей доступных одному клиенту; установить балансировку индексов и задать опцию создания файлов в форматах предшествовавших 6.x; здесь же устанавливается будет ли микроядро вести журнал действий над выбранными файлами. В этом разделе выбирается механизм совместного использования файлов. Пункт «system transaction» содержит ограничение, устанавливающее количество системных транзакций выполняемых в процессе операции записи в совместно-используемые файлы.
• Memory organisation: — эта категория содержит настройки размеров буферов, резервируемых микроядром для различных нужд.
• Client/System transactions: — здесь находятся настройки параметров транзакций, включая количество поддерживаемых транзакций, где и как они будут записаны в журнал.
• System resources/directories: — здесь содержатся настройки количества обслуживаемых клиентов и поддерживаемых потоков, а также места размещения различных системных файлов.
• Trace operations: — содержит настройки трассировки для различных операций выполняемых Btrieve.

Pervasive.SQL 7

Pervasive SQL 7 был выпущен в марте 1998 и включал в себя Scalable SQL 4 и Btrieve 7.0. Btrieve 7.0 запускалась на тех же платформах, что и Btrieve 6.x: Windows 95, Windows NT 3.51 & 4, Netware и DOS. Тем не менее компания изменила компонентную архитектуру именуемую SmartComponents для решения вопросов совместимости при переходе на новую версию. Она использовала схему идентификации компонентов с одновременным указанием идентификатора внутри файла и кодированием в его имени, совместно с динамическим связыванием «склеивающих модулей». Динамическое связывание компонентов выполнялось с применением нового подхода, «Abstract OS Services DLL», в соответствии с которым выбиралась самая последняя версия необходимого компонента, посредством информации закодированной в его имени файла. Далее, этот «склеивающий модуль» загружался в память и начинал использоваться. Старый формат файла журнала событий, существовавший в Btrieve 6.x, был заменён новым централизованным журналом PVSW.LOG, имеющим усовершенствованный и унифицированный формат. Также были улучшены сами сообщения об ошибках и механизм их порождения.

MKDE сохранилось в Pervasive.SQL 7. Тем не менее, его внутренняя архитектура изменилась, вследствие появления новой архитектуры динамического связывания компонентов. Приложение использующее Btrieve вызывало специального сервис-менеджера, который искал в различных, указанных в конфигурации, директориях файлы с именами определённого формата. Вот определение шаблона для имён этих файлов в формате BNF:

<filename> ::= <platform-code> "BIF" <major-functional-level> <minor-functional-level>
<platform-code> ::= "W1" | "W2" | "W3" | "W9" | "WT" | "NW" | "O3"
<major-functional-level> ::= <number>
<minor-functional-level> ::= <number> <number>
<number> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

«Склеивающий» модуль загружается в память и становится интерфейсом к MKDE. Далее MKDE определяет, каким образом оно настроено, для работы на отдельной рабочей станции или для взаимодействия с сервером, и начинает транслировать запросы на сервер БД или напрямую работать с файлами БД, если оно настроено на режим «рабочая станция».

Pervasive.SQL 2000/2000i

Pervasive.SQL 2000 и 2000i используют по существу ту же архитектуру, что и Pervasive.SQL 7, но 2000i и включает дополнительный сервер i*Net. Используется та же компонентная модель, позволяющая использовать оба механизм доступа к данным, и Btrieve и Scalable SQL; продолжается использоваться архитектура MKDE. Эта версия включает поддержу Red Hat Linux, Caldera OpenLinux, SUSE и Solaris. Также была улучшена интеграция с Terminal Services, хотя возможно запускать только один экземпляр ядра СУБД на любой платформе. То есть невозможно запустить отдельные копии СУБД в двух или более терминальных сеансах.

Pervasive.SQL V8

Представленный в декабре 2002 г. Pervasive.SQL V8 имеет улучшенные характеристики производительности для приложений использующих любой из механизмов доступа, что достигнуто использованием нескольких новых технологий:

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

Пакет обновлений V8 Security Feature Pack внёс важные изменения в модель безопасности, направленные на ограничение доступа к файлам данных. До версии 8.5 доступ к данным Btrieve контролировался механизмами безопасности ОС, что означало буквально: «Пользователь осуществляющий чтение/запись данных, должен иметь доступ на чтение/запись к соответствующим файлам с данными». В новой версии реализована новая модель безопасности, позволяющая администратору контролировать доступ к данным Btrieve используя собственный механизм разграничения доступа СУБД. После активации нового механизма, пользователь более не нуждается в доступе к файлам данных. В дополнение, конфигурации с архитектурой клиент/сервер более не нуждались в использовании общих сетевых ресурсов или их отображении в виде виртуальных дисков. Теперь приложения могли ссылаться за защищённые данные Btrieve посредством URI-строк соединения.

Pervasive PSQL v9

Pervasive PSQL v9 включает новый Java GUI, на основе Eclipse, доступный как для Microsoft Windows, так и для Linux. Также, v9 содержит множество обновлений SQL, как по части производительности, так и по части синтаксиса, способствующих повышению скорости и улучшению функциональности всех средств доступа, использующих SQL — ADO.Net, JDBC, ODBC и OLE DB. И в заключение, PSQL v9 увеличивает максимальный размер файла БД с 64GB, в 8.x и более ранних версиях. до 128GB в 9.0 и 256GB в 9.5.

Совместно с выпуском PSQL v9, была вновь релизована утилита DDF Builder, а кроме того добавлена поддержка полнотекстового поиска, обеспечиваемая дополнением Full Text Search. DDF Builder предоставляет возможность пользователям Btrieve задать метаданные для существующих файлов формата Btrieve, чтобы сделать их доступными для SQL утилит.

Все версии MKDE сохраняют обратную совместимость с предыдущими версиями Btrieve на уровне чтения данных. В том числе поддерживаются версии выпущенные до появления MKDE, и формат файла не изменяется до тех пор, пока это специально не запрошено. Однако, файлы от версий 5.x и более ранних должны быть перестроены заново, в формат версии 6.x или более поздней, для обеспечения возможности их изменения ядром СУБД версии 9.0 или более поздней. Перестройка выполняется из графического интерфейса или консольной командой Rebuild.

Pervasive PSQL и сопутствующие продукты

В настоящее время Pervasive поставляет набор дополнительных продуктов, расширяющих базовые возможности СУБД PSQL.

• Pervasive AuditMaster предоставляет средство аудита всех взаимодействий с БД в реальном времени, как через Btrieve, так и посредством SQL. Журнал действий над данными можно просмотреть, чтобы отследить изменения чувствительных данных. Также он может порождать события-предупреждения, информирующие соответствующих сотрудников или запускающие связанные с этим событием процессы.
• Pervasive Backup Agent — обеспечивает непрерывное функционирование PSQL, позволяя ПО резервного копирования выполнять копирование работающей БД.
• Pervasive DataExchange — осуществляет синхронизацию и репликацию данных между двумя и более инсталляциями PSQL, обеспечивая постоянную доступность критических данных.