Ім'я файлу: Створення баз даних в InterBase SQL Server.doc
Розширення: doc
Розмір: 35кб.
Дата: 09.08.2021
скачати
Пов'язані файли:
курсова.Зелінська.docx
Розширення: doc
Розмір: 35кб.
Дата: 09.08.2021
скачати
Пов'язані файли:
курсова.Зелінська.docx
Я не буду захаращувати текст докладним описом всіх операторів для створення об'єктів в базі даних. Для цього є документація. Навпаки, на простих прикладах спробую показати як і коли потрібно робити так або інакше. Тут описується робота з SQL сервером InterBase 6.0.
Створення бази даних
База даних створюється простим скриптом. Тут і надалі я буду SQL оператори виділяти жирним шрифтом.
CREATE DATABASE '... PFO_POKAZATELI.GDB' USER 'ADM_PFO_POK' PASSWORD '12345 '
PAGE_SIZE = 8192
DEFAULT CHARACTER SET WIN1251;
CREATE DATABASE - це і є оператор, який створить базу даних. База даних буде представляти із себе файл, який буде створений в каталозі, вказаному після оператора. Розширення файлу може бути будь-яким, але прийнято, що GDB - розширення для файлу бази даних, а, наприклад, GBP - для резервної копії.
USER і PASSWORD задають ім'я користувача та пароль. Цей користувач повинен бути зареєстрований на сервері до створення бази даних, інакше InterBase видасть повідомлення про помилку.
PAGE SIZE задає розмір сторінки даних у файлі за замовчуванням. Сторінка буде викачуватися з жорсткого диска тільки цілком. Тому, можна вважати, що це мінімальний розмір буфера роботи з файлом бази даних. Сторінка повинна бути такого розміру, щоб у неї помістилася хоча б один запис в будь-якій з таблиць. Тут не потрібно враховувати розмір BLOB поля, тому що для його зберігання виділяються додаткові сторінки. Розміри сторінок можуть бути від 1024 до 8192 Kb. Розмір сторінок впливає на швидкодію і ступінь заповнення даними файлу бази даних. Так, якщо такий запис не поміщається цілком у активну сторінку, то для неї буде виділена нова сторінка. Тому слід прагнути до кратному сторінці розміром запису. Це, звичайно дуже проблематично, тому що у Вас в БД може бути кілька таблиць з різними розмірами запису. Занадто великий розмір сторінки призводить до зчитування з диска записів, які можуть не знадобитися у вихідних даних запиту, що повинно знижувати швидкодія всієї системи в цілому. Очевидно, це відбувається при маленьких розмірах запису в порівнянні з розміром сторінки. Проте, численні досліди показують, що швидкодія може і знижується, але на таку маленьку величину, яку неможливо зафіксувати і виміряти в реальних грамотно побудованих додатках.
DEFAULT CHARACTER SET визначає кодування символів в базі даних. Якщо Ви маєте намір використовувати російську мову, то Вам слід встановити значення WIN 1251. Для інших мов є свої кодіровочного таблиці. Зазвичай базу даних створюють в IBConsole. Там потрібно вибрати пункт меню "Database | Create Database". У вікні заповнити поля введення параметрів операторів для створення БД.
Ви можете створити БД з декількох файлів, які будуть заповнюватися даними по черзі. Або створити дзеркало на іншому жорсткому диску для захисту від краху основного жорсткого диска (див. документацію). Створення таблиць
InterBase - це не зовсім те, про що писав Кодд. Тут повністю не реалізовано поняття домену. Домени служать в InterBase не для зв'язку таблиць по первинному та зовнішньому ключу, а для опису типу поля, визначеного користувачем. Більш того, якщо Ви почнете створювати таблиці з полями стандартного типу, то кожному з цих полів буде поставлений у відповідність свій домен. Це призводить до того, що кількість об'єктів в базі даних приростає за рахунок доменів прямо пропорційно кількості полів всіх таблиць. Тому, зазвичай створюють достатню кількість доменів для опису таблиць в БД, а потім створюють самі таблиці. Ось витяг з реальної бази даних для створення доменів:
CREATE DOMAIN IZMER_NUM INTEGER NOT NULL;
CREATE DOMAIN ACTIVITIES_NUM INTEGER NOT NULL;
. . .
CREATE DOMAIN NAMES_TYPE VARCHAR (45) COLLATE PXW_CYRL;
CREATE DOMAIN FLOAT_TYPE DOUBLE PRECISION;
CREATE DOMAIN BOOL_TYPE CHAR (1) DEFAULT "F" CHECK (VALUE = "T" OR VALUE = "F");
CREATE DOMAIN FORMULA_TYPE BLOB SUB_TYPE 1 SEGMENT SIZE 256 CHARACTER SET WIN1251;
CREATE DOMAIN INTEGER_TYPE INTEGER;
. . .
CREATE DOMAIN BY_USER VARCHAR (30) DEFAULT USER;
CREATE DOMAIN BY_DATE TIMESTAMP DEFAULT "now";
Команда CREATE DOMAIN створює новий домен. Далі, йде ім'я домену. Потім - його тип. Є безліч типів даних, які підтримує InterBase. Ви можете дізнатися цю інформацію з документації. Далі, можна поставити обмеження на значення, що заводяться в полі таблиці типу цього домену. Наприклад, NOT NULL зобов'язує завжди заводити якісь дані в це поле при додаванні нового рядка в таблицю, тобто це поле обов'язково повинно бути заповнене. DEFAULT "F" заповнює поле значенням за замовчуванням - символом "F". Конструкція CHECK (VALUE = "T" OR VALUE = "F") перевіряє вихід значення поля за задані межі. Конструкція COLLATE PXW_CYRL дозволяє правильно вести сортування рядків таблиці по полю типу цього домену. Ця конструкція застосовується при створенні домену або під час оголошення індексу (про це пізніше). Конструкція CREATE DOMAIN FORMULA_TYPE BLOB SUB_TYPE 1 SEGMENT SIZE 256 CHARACTER SET WIN1251 створює домен типу BLOB, тобто набір байтів, які розглядаються як текст (SUB_TYPE 1), сторінки у файлі БД для цього тексту виділяються по 256 байт відразу і текст у цьому полі записується в кодуванні WIN1251. Останні два домени можуть зберігати інформацію про користувача і дату і час про останній зміни запису. Тепер створимо якусь таблицю.
CREATE TABLE IZMER_NAMES
(
ID_NUM IZMER_NUM,
NAME NAMES_TYPE,
USER_NAME BY_USER,
CHANGE_DATE BY_DATE,
PRIMARY KEY (ID_NUM)
);
Оператор CREATE TABLE власне, створює таблицю, далі йде її унікальне в межах БД ім'я. Між дужками стоять визначення стовпчиків таблиці і додаткові оператори. Ми бачимо, що таблиця складається з чотирьох стовпчиків, а їх тип описаний через домени, які ми описали раніше. Якщо Ви створите ще одну таблицю з полем типу NAMES_TYPE, то кількість доменів у Вас не збільшиться, а якщо б Ви створили дві таблиці, у яких було б по одному полю типу VARCHAR (45), то це привело б до створення двох доменів, що описують ці поля. Причому, імена цих доменів присвоїли б за замовчуванням, а значить, абсолютно нечитабельні. Оператор PRIMARY KEY ії ім'я або імена полів, які розглядаються як первинний ключ. Поля первинного ключа повинні бути NOT NULL і поєднання їх значень повинна бути унікальною в межах таблиці. Це як би відбиток пальців запису - набір значень полів, за якими ми завжди зможемо відрізнити один запис від іншого. Якщо Ви не можете виділити первинний ключ у таблиці для зберігання Ваших даних, значить, швидше за все, Ви недостатньо добре продумали всі питання зі зберігання даних у табліце.Связиваніе таблиць
Зв'язати можна хоча б дві таблиці, а тому визначимо другу:
CREATE TABLE ACTIVITIES
(
ID_NUM ACTIVITIES_NUM,
ID_IZMER_NAMES IZMER_NUM,
POZITION INTEGER_TYPE,
NAME NAMES_TYPE,
IS_DECCIPHERAD_INFO BOOL_TYPE,
USER_NAME BY_USER,
CHANGE_DATE BY_DATE,
PRIMARY KEY (ID_NUM),
FOREIGN KEY (ID_IZMER_NAMES) REFERENCES IZMER_NAMES (ID_NUM));
У другій таблиці є поле з типом IZMER_NUM - це домен, який використовується в першій таблиці для визначення поля первинного ключа. Ми можемо створити зовнішній ключ для зв'язку двох таблиць: FOREIGN KEY (ID_IZMER_NAMES) REFERENCES IZMER_NAMES (ID_NUM). Що буквально означає: "Зовнішній ключ по полю ID_IZMER_NAMES як посилання в таблицю IZMER_NAMES по полю ID_NUM". Такий зв'язок гарантує нам, що в таблиці IZMER_NAMES завжди буде присутній рядок з номером, який ми запишемо в полі ID_IZMER_NAMES. Якщо хто-небудь спробує видалити з довідника одиниць вимірювання рядок, яку ми використовуємо в довіднику діяльності, то відбудеться виняткова ситуація. Така поведінка БД називається контроль посилальної цілісності. Тепер, трохи слів про план побудови БД. Добре, якщо у Вас є якийсь ніякої Case інструмент, наприклад, Rational Rose. Кажуть, що в Microsoft Office з'явився Visio. Я підозрюю, що це щось не зовсім те, що потрібно, але краще зараз працювати хоч на чомусь, що довго чекати хороший інструмент. Ну, а якщо немає Case, то слід враховувати ряд невеликих правил:
Складіть текст БД, а потім вводите запити. Текст стане в нагоді Вам для перевірки перед введенням. У процесі введення, Ви знайдете ряд помилок, які відразу заносите в текст БД (скрипт).
Спочатку створюються довідники, які не мають зовнішніх зв'язків, потім ті таблиці, які мають зв'язки на ці довідники і т.д. від простого до складного, або Вам доведеться все зв'язку визначати після створення таблиць.
Не використовуйте для створення БД візуальні програми типу Database Desctop або SQL Explorer. Вводьте все у вигляді SQL запитів, наприклад в Interactive SQL. Принаймні, Ви точно будете знати який саме запит Ви намагаєтеся виконати.
Сурогатні ключі
Є два типи ключових полів. Перше - це природні ключі. Візьмемо, приміром, медичну картку в поліклініці. Природний ключ - це номер медичної карти. На медичну карту "чіпляються" талони (зв'язок головний - підлеглі), у яких природний ключ - це номер медичної карти хворого, звітний рік і номер талона (з нового року нумерація починається з одиниці). До талонами "чіпляються" відвідування, у яких природний ключ - номер медичної карти хворого, звітний рік, номер талона і дата відвідування. До відвідинам - послуги і т.д. Ми бачимо, що розмір первинного ключа збільшується, принаймні, на одне поле з кожною новою таблицею. Відповідно, зростає обчислювальна навантаження, яку можна оцінити потужністю домену, на сервер БД. Як же можна протистояти розростанню первинного ключа? Багато програмістів, і я в тому числі, вважають, що унікальність запису і первинний ключ - це поняття, взагалі-то різні, тому ми завжди, де це потрібно, застосовуємо т.зв. скорочення первинного ключа. Для цього використовуються сурогатні (тобто неприродні) ключі. Що таке сурогатний ключ? Це поле цілого типу, яке має унікальне значення, який утворює домен з іншими таблицями. Візьмемо, для прикладу, випадок з поліклінікою. Для таблиці з талонами вводиться унікальне поле цілого типу, в якому буде зберігається послідовність цілих чисел 1, 2, 3 ... N і т.д. Це поле оголошено первинним ключем, а щоб не завести декілька талонів з однаковими номерами, оголошується унікальний індекс по полях звітний рік і номер талона. Зовнішній ключ, як і належить - по полю номера медичної карти. У результаті, ми скоротили розмір первинного ключа, який тепер є сурогатним. Ці цілі числа будуть використовуватися в таблиці з відвідинами, де теж можна скорочувати первинний ключ. Зауважте, що в таблиці з відвідинами, тепер, не потрібно зберігати не номер медичної карти, не звітний рік, не номер талона, а тільки значення первинного ключа, тобто одне ціле число на запис.
Ось декілька прикладів для роботи з сурогатними ключами.
Для початку, потрібно створити механізм підтримки унікальності значень сурогатного ключа.CREATE GENERATOR GET_IZMER_NAMES_NUM;
Цей оператор створює т.зв. генератор, де буде зберігається попереднє значення нашої унікальної послідовності цілих чисел. Механізм гарантує, що тільки один користувач може мати доступ до генератора в один момент часу. Інші будуть чекати, поки генератор не звільниться.
SET GENERATOR GET_IZMER_NAMES_NUM TO 50;
Цим оператором ми встановили початкове значення генератора. Далі, можна або створити тригер, який спрацює при додаванні нового запису в таблицю, або створити простеньку процедуру, яка поверне чергове значення з генератора:
SET TERM!! ;
CREATE PROCEDURE SET_IZMER_NAMES_NUM
RETURNS (NUM INTEGER)
AS
BEGINNUM = GEN_ID (GET_IZMER_NAMES_NUM, 1);
END!!
SET TERM;!!
GEN_ID - це вбудована процедура, яка просто збільшує значення генератора на величину, передану в другому параметрі і повертає результат. Якщо Ви використовуєте тригер, то після додавання нового запису, Вам доведеться оновлювати весь набір даних, щоб знати значення первинного ключа, тому краще використовувати процедуру.
"Дерев'яні" списки
Бувають випадки, коли відношення головний-підлеглий притаманне записам одній і тій же таблиці, наприклад, відносини між відділами організації або між структурами держапарату і т.д. і т.п. Один запис може бути головною для кількох інших, які в свою чергу можуть бути головними для наступних. Така структура нагадує дерево з гілками, розташованими вниз по таблиці. Перший запис (записи) - головний вузол (вузли) від яких йдуть гілки (підлеглі запису). Якщо ці записи мають свої підлеглі (вкладені) запису, то вони утворюють такі за ієрархічним списком вузли. Простіше за все, представити це у просторі у вигляді шарів записів. Кожен запис може містити в собі вкладений шар із записами. Незважаючи на всю складність, що здається, реалізація такої структури дуже проста. Для цього потрібно мати, як мінімум, два стовпчики в таблиці: перший стовпчик - це сурогатний первинний ключ, а другий - посилання на перший стовпчик із значенням первинного ключа запису - власника. Ось реалізація такої таблиці:
CREATE TABLE ACTIVITIES
(
ID_NUM ACTIVITIES_NUM,
ID_OWNER ACTIVITIES_NUM,
ID_IZMER_NAMES IZMER_NUM,
POZITION INTEGER_TYPE,
NAME NAMES_TYPE,
USER_NAME BY_USER,
CHANGE_DATE BY_DATE,
PRIMARY KEY (ID_NUM),
FOREIGN KEY (ID_IZMER_NAMES) REFERENCES IZMER_NAMES (ID_NUM));
Таблиця містить первинний ключ в поле ID_NUM, посилання на головну запис у полі ID_OWNER, посилання на одиницю виміру в полі ID_IZMER, поле POZITION цілого типу, що визначає позицію запису, для можливості переміщення записи вгору і вниз, найменування виду дечтельності в поле NAME. Далі, йдуть лічильник і процедура для роботи з первинним ключем.
CREATE GENERATOR GET_ACTIVITIES_NUM;
SET GENERATOR GET_ACTIVITIES_NUM TO 50;
SET TERM!! ;
CREATE PROCEDURE SET_ACTIVITIES_NUM
RETURNS (NUM INTEGER)
AS
BEGINNUM = GEN_ID (GET_ACTIVITIES_NUM, 1);
END!!
SET TERM;!!
Далі, йде індекс для сортування рядків за позиції. Ім'я POZITION прийнято мною не тому, що я не знаю про англійському слові POSITION, а тому, що POSITION - зарезервований ідентифікатор SQL.
CREATE UNIQUE INDEX ACTIVITIES_POSITION ON ACTIVITIES (ID_OWNER, POZITION);
Тригер UPDATE_ACTIVITIES оновлює значення полів, ідентіфіцірующіз користувача вніс останні зміни.
SET TERM!! ;
CREATE TRIGGER UPDATE_ACTIVITIES FOR ACTIVITIES
BEFORE UPDATE AS
BEGIN
NEW.USER_NAME = USER;
NEW.CHANGE_DATE = 'now'
END!!
SET TERM;!!
Нарешті, доданий зовнішній індекс таблиці на саму себе. В описі таблиці це не можна було зробити, тому що ні поля ID_OWNER, ні поля ID_NUM, ні самої таблиці не існувало.
ALTER TABLE ACTIVITIES
ADD
FOREIGN KEY (ID_OWNER) REFERENCES ACTIVITIES (ID_NUM) ON DELETE CASCADE;
Далі, йде процедура переміщення рядка в шарі даних вгору або вниз. Мається на увазі, що в шарі не більше 2147483646 рядків.
SET TERM!! ;
CREATE PROCEDURE SET_ACTIVITIES_POSITION (OWNER_NUM INTEGER, OLD_POSITION INTEGER, NEW_POSITION INTEGER)
AS
BEGINUPDATE ACTIVITIES
SET
POZITION = 2147483647
WHERE
POZITION =: NEW_POSITION AND
ID_OWNER =: OWNER_NUM;
UPDATE ACTIVITIES
SET
POZITION =: NEW_POSITION
WHERE
POZITION =: OLD_POSITION AND
ID_OWNER =: OWNER_NUM;
UPDATE ACTIVITIES
SET
POZITION =: OLD_POSITION
WHERE
POZITION = 2147483647 AND
ID_OWNER =: OWNER_NUM;
END!!
SET TERM;!!
Тут не вистачає тільки тригера для початкового визначення значення поля POZITION. Я думаю, що Ви зможете самостійно створити тригер як проби сил.
Робота з подіями
Це зовсім просто:
SET TERM!! ;
CREATE TRIGGER CHANGE_ACTIVITIES FOR ACTIVITIES
AFTER UPDATE POSITION 0 AS
BEGIN
POST_EVENT 'Update Activities!';
END!!
SET TERM;!!
Залишилося тільки зареєструвати цю подію в додатку користувача, і якщо воно відбудеться на сервері, то додаток користувача його отримає. Так можна, наприклад, спостерігати за змінами курсів валют на біржі. При зміні курсу, клієнт отримує подія і пере відкриває запит, щоб побачити зміни.
Робота з винятками
Для початку, виключення потрібно визначити в БД.
CREATE EXCEPTION DELETE_MAIN_PARENT 'DO NOT DELETE THIS RECORD! THIS RECOCT IS PARENT FOR ALL RECORDS. ';
Далі, потрібно визначити тригер, який зловить виняткову ситуацію. Наприклад, при видаленні головного узда дерева, віддалиться вся БД цілком. Зрозуміло, що такого бути не повинно. Давайте зловимо це виняток.
SET TERM!! ;
CREATE TRIGGER CHECK_DELETE_TYPES FOR ACTIVITIES
BEFORE DELETE POSITION 0 AS
BEGIN
IF (ACTIVITIES.ID_NUM = ACTIVITIES.ID_OWNER) THEN
EXCEPTION DELETE_MAIN_PARENT;
END!!
SET TERM;!!
Якщо виняткова ситуація настане, то користувачеві нічого не залишиться зробити, окрім як скасувати транзакцію.
Процедури, тригери
Поняття процедур і тригерів має, передусім, асоціюватися з поняттям бізнес-логіка. Процедури реалізують документований інтерфейс до даних в БД, а тригери - перевірку коректності введення даних і закулісну роботу. Якщо у Вас є можливість перекласти всю бізнес-логіку на сервер у вигляді тригерів і процедур, то так і треба чинити. Навіть якщо Ви в програмі контролюєте правильність даних, що вводяться, не забудьте в БД продублювати це ж у тригері. Такий підхід гарантує, що при написанні додаткового модуля або ще однієї програми, що оперує з даними БД, Вам не вдасться порушити правила роботи з даними. Я думаю, що прикладів тригерів і процедур було достатньо. Але, починаючі програмісти часто відмовляються від використання цього наймогутнішого механізму БД із за прикрих помилок в синтаксисі запитів. Їм здається, що в додатку користувача легше зробити те ж саме, до того ж і працює воно швидше ... Це помилка. Одна справа, коли Ви пишете і тестуєте програму локально, і зовсім інше, коли до БД підключені користувачі. Ніяка програма не зробить зміни в БД так само швидко і коректно, як вбудовані механізми. Ось тоді вони будуть працювати локально, а ваша програма - по мережі. Тому я дам без коментарів приклад процедури з великою кількістю операторів. З цього прикладу буде ясно де ставити, а де немає крапки з комами, двокрапки і т.д. Думаю, що це допоможе Вам у Ваших розробках.
SET TERM!! ;
CREATE PROCEDURE CHECK_USER_SECURITY (ID_USER INTEGER, ID_DOC INTEGER, UP_TREE INTEGER)
RETURNS (IS_SHOW CHAR (1), IS_EDIT CHAR (1), IS_APPEND CHAR (1), IS_DELETE CHAR (1))
AS
DECLARE VARIABLE TREE_NUMBER INTEGER;
DECLARE VARIABLE TREE_OWNER INTEGER;
DECLARE VARIABLE USER_NUM INTEGER;
DECLARE VARIABLE DOC_NUM INTEGER;
DECLARE VARIABLE EDITING CHAR (1);
DECLARE VARIABLE APPENDING CHAR (1);
DECLARE VARIABLE DELETING CHAR (1);
BEGINIS_EDIT = 'F';
IS_APPEND = 'F';
IS_DELETE = 'F';
IS_SHOW = 'F';
FOR SELECT ID_NUM, ID_OWNERFROM DATA_LIST
WHERE DATA_LIST.ID_NUM =: ID_DOC
INTO TREE_NUMBER, TREE_OWNER
DO
BEGIN
IF (TREE_NUMBER = UP_TREE) THEN EXIT;
FOR SELECT ID_USER, ID_DOC, IS_EDIT, IS_APPEND, IS_DELETE
FROM DOCS_USERS
WHERE DOCS_USERS.ID_USER =: ID_USER
INTO USER_NUM, DOC_NUM, EDITING, APPENDING, DELETING
DO
BEGIN
IF (TREE_NUMBER = DOC_NUM) THEN
BEGIN
IS_EDIT = EDITING;
IS_APPEND = APPENDING;
IS_DELETE = DELETING;
IS_SHOW = 'T';
EXIT; END
END
ID_DOC = TREE_OWNER; END
END!!
SET TERM;!!
Ця процедура використовується сервером додатків для перевірки прав користувача в таблиці у вигляді ієрархічного дерева. Зрозуміло, що визначити права користувача до окремого запису стандартними шляхами не можна, тому вся БД працює під управлінням сервера додатків і за допомогою DCOM дає інтерфейси клієнтам. Оскільки сервер додатків запущений в адресному просторі сервера, то такий підхід до Security можна вважати виправданим.
UDF функції
Зазвичай, тут дають приклад, як порахувати яку-небудь математичну формулу, і повернути її результат як стовпчик відповіді на запит. Я ж вирішив показати приклад з рядками, тому що це перше, на чому звичайно вперше спотикаються. Це тільки приклад. У реальному БД такого не роблять. Отже, додамо в таблицю ACTIVITIES полі TREE_INFO VARCHAR (255). Будемо в ньому зберігати шлях від головного вузла. Цей шлях найпростіше будувати в тригері з додавання запису до таблиці. Але сам рядок з шляхом буде створюватися в DLL. Для початку оголосимо нащу функцію в DLL:
DECLARE EXTERNAL FUNCTION CREATEPATH (CSTRING (256), INTEGER)
RETURNS CSTRING (256)
ENTRY_POINT "CreatePath"
MODULE_NAME "UDF_INCL";
Ми вказали ім'я в БД, що передаються переметров, повертається значення, ім'я в DLL, і ім'я самої DLL. Ця бібліотека повинна знаходиться в каталозі UDF. У мене це D: Program FilesBorlandInterBaseUDF. А використовувати функцію будемо так:
SET TERM!! ;
CREATE TRIGGER INSERT_ACTIVITIES FOR ACTIVITIES
BEFORE INSERT
AS
DECLARE VARIABLE PATH_TREE VARCHAR (256);
BEGIN
SELECT TREE_INFO
FROM ACTIVITIESWHERE (NEW.ID_OWNER = ID_NUM)
INTO PATH_TREE;
NEW.TREE_INFO = CREATEPATH (PATH_TREE, NEW.ID_NUM);
END!!
SET TERM;!!
У InterBase всі UDF передають в параметрах посилання, тому рядок передають як покажчик. Використовуються VARCHAR рядка, тому що вони явно не доповнюються пробілами до максимальної довжини. Інакше, Ви б вже нічого до неї не додали. Ось реалізація DLL в Delphi:
library UDF_INCL;
/ /
/ /
/ / Copyright 2000 Bannikov NA Stikriz Technology
/ /
/ /
uses
SysUtils,
Classes;
{$ R *. RES}
function CreatePath (MainPath: PChar; var IntVal: LongInt): PChar; cdecl; export;
begin
Result: = PChar (AnsiString (MainPath) + IntToStr (IntVal )+'');
end;
exports
CreatePath;
begin
end.
Список літератури
Банніков Н.А. Створення баз даних в InterBase SQL Server.
//ua-referat.com