Я багато бачив різних країн. але це для того, щоб сказати, що я все-таки заповажав корпорацію Microsoft, після докладного знайомства з Лінукс-му. І ось чому. Операційна система Windows - найбільш проста і доступна для користувачів, хто не присвятив своє життя комп'ютера. У жодній комерційній, а тим більше безкоштовної, системи немає настільки простих і доступних елементів настройки як в Windows. І це тільки моя точка зору. Я не хочу розводити дебати на цю тему, тому, що хочу розповісти про свої напрацювання і дослідженнях. Вони стосуються, на мою думку, однією з кращих і розвинених локальних баз даних - Microsoft Jet або mdb. При певних зусиллях можна написати навіть непогану мережеву програму на базі mdb.
Навіщо це потрібно?
За роки моєї роботи з mdb (близько 6 років) я один раз зіткнувся з ситуацією, коли базу даних Access не вдалося відновити після раптового відключення живлення (Про UPC-ах і мови не було). Та й необхідність відновлення виникала лише раз 5. До того ж, підтримка Jet вбудована в Windows, і немає необхідності шукати (купувати) і встановлювати драйвер для бази даних. Всі інші формати більш схильні до руйнування, або складаються з безлічі файлів; при відсутності одного з цих файлів говорити про цілісність даних важкувато. Я готовий обговорити це факт.
Почав з простого вікна, в якому було TMemo - для тексту запиту, і кнопка для виконання цього запиту. CheckBox - для вказівки, повертати мені результат запиту, чи ні. Друге вікно відкривалося з DBGrid-му, в якому був результат виконання запиту. Третє вікно - ListBox, який містив список таблиць і запитів бази даних (макроси, звіти і форми Access я не вмію діставати і зараз, навіть не знаю де це ховають). За подвійним клацанням на елементі списку відкривалося все той-же вікно з DBGrid-му, де можна було подивитися вміст таблиці або запиту.
Першу базу даних я створив за допомогою системного менеджера ODBC - там є така можливість! Перші таблиці доводилося створювати за допомогою інструкцій SQL. Я був приємно здивований, що Access вміє через SQL такі речі, які ніде в довідці по Access не описані. До цих можливостей відноситься параметр DEFAULT в інструкції CREATE TABLE. У довідці до Access про нього немає ні слова! А в довідці по InterBase - є. Я спробував - дуже прекрасно встановлюються значення за замовчуванням для поля повинна містити таблиця. Коротше кажучи, хто шукає - знайде. Перші запити і процедури доводилося зберігати в текстовому вигляді, щоб після коригування видалити з бази даних збережений запит і внести відкоригований. Потім я спробував дістати текст запиту з бази даних через ADO - не вийшло, не вийшло і до сих пір. Довелося вибрати інший шлях. Якщо це робить Microsoft - чому не можу це робити я?
Так ось, якщо подивитися в системні таблиці, то там є вся необхідна інформація (або майже вся). Використовуючи її можна написати парсер, який буде збирати текст запиту, використовуючи формат запису самої Microsoft. А зберегти потім змінений запит (пам'ятаємо: або процедуру) з допомогу інструкції CREATE VIEW або CREATE PROCEDURE.
Формат зберігання SQL запиту в Access.
Відразу обмовлюся, що все це можливо тільки з правами адміністратора на базу даних (Ще один плюс на користь Access).
Нижче наводжу таблицю з описом всього, що мені вдалося розкопати з цього приводу. Використовуючи цю інформацію, я написав парсер, який збирає це все в текст запиту. Я не претендую на повноту викладу, тому, що ще не повністю розібрав цю інформацію, але можливо це допоможе комусь. Буду радий допомоги, якщо хтось щось знає по цій темі. Принаймні відсотків 70 запитів розшифровуються і виконуються так як було задумано.
Угоди по позначеннями: Якщо щось не описано - я не розбирався - не було необхідності, або Чи не наводить на думку.
- Знаки. позначають, що я дуже сумніваюся в правильності описаної інформації.
- Порожні осередки - в моїй практиці не зустрічалося.
- [Щось] - узагальнений тип значення, наприклад якщо в поле зустрічається тільки 1 або 2 або 3 - я пишу Integer, навіть есл
- тип поля - текстовий.
- змінна або значення. - . - частина запиту не критична для опису. (для наочності).
- Опис курсивом - те, що знадобиться для розбору запиту.
Зовнішній вигляд записи таблиці MSysObjects (всі об'єкти бази даних).
Хоча в Access і не робиться розходження між запитом і процедурою, насправді воно є в ADO. Запитом вважається простий запит SQL без параметрів, який називається VIEW. Всі запити на зміну структури таблиць, запити з параметрами, запити на об'єднання та ін. Вважаються процедурами і вибіраютя з бази даних як views або procedures відповідно. Запити зберігаються в базу даних відповідно за допомогою CREATE VIEW, а процедури - CREATE PROCEDURE. Якщо ви додали в запит параметри, він перетворився в процедуру, і назад зберігати його потрібно вже за допомогою CREATE PROCEDURE. Так, і перед збереженням зміненого запиту не забувайте видаляти з бази попередній - DROP VIEW або DROP PROCEDURE. До речі запит (view) віддаляється і інструкцією DROP TABLE, однак я б не рекомендував нею користуватися, тому що помилка в імені, або неуважність - і ви видалите замість запиту таблицю. За допомогою DROP VIEW таблицю видалити не можна. Цей варіант більш безпечний. За допомогою DROP VIEW можна видалити процедуру, але, знову ж таки краще користуватися призначеної інструкцією - принаймні ви будете чітко розуміти, що робите.
Опис полів і їх значень відносяться до запиту (процедурі).
Формат зберігання запитів в Access (MsysQueries) Значення ObjectID і ім'я запиту знаходиться в таблиці MsysObjects
Цей же ID міститься у всіх інших записах, що відносяться до цього запиту
Порожня запис (я не зустрічав її заповненої)
Йде після Attribute 0 завжди
Тип запиту, визначається полем Flag. Присутній не завжди. Якщо запис відсутній, то це (швидше за все, так інших варіантів і не зустрічалося) запит SELECT