Створення баз
даних в InterBase SQL Server
Я не буду захаращувати текст докладним
описом всіх операторів для створення об'єктів у базі даних. Для цього є
документація. Навпаки, на простих прикладах спробую показати як і коли
потрібно робити так чи інакше. Тут описується робота з 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 N.A. 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.
Для підготовки
даної роботи були використані матеріали з сайту http://delphid.dax.ru
.
