Tips & tricks за IBexpert, Firebird и базите от данни

Tips & tricks за IBexpert, Firebird и базите от данни

Мнениеот mIRCata » 15-12-2009 13:38

Тъй като вече програмите минават основно на работа с Firebird SQL и понякога се налага да се оправят грешки или да се правят корекции директно в базата данни, реших да сложа тук няколко разяснения по работата с IBExpert и неговото конфигуриране. Както и няколко насоки за самата база данни, която да помогне за по-лесното и бързо локализиране на възникнал проблем.
Ще опиша и използването на Aliases във Firebird, за да се избегне помненето на дълги и сложни пътища за мястото на базата данни. Освен, че е по-кратко и лесно за помнене, скрива физическото място на базата данни във файловата система. Поне в ini файла, че програмите сега го показват :)

I. Настройки на IBExpert

Първо ще започна с настройките на IBexpert - някои от тях са по желание и касаят визуализирането, но други е препоръчително да се сложат за да се избегнат проблеми.

Първите настройки са в Options->Environment options
Отделните настройки от дървото са:
Preferences :

User interface - ползвайте както ви харесва. Лично аз го направих на MDI, за да ми се зарежда всичко в един прозорец, а не ми хвърчат по екрана и да се припокриват едни с други.
Default server version - Firebird 2.1. Има места в базата, където ако не е направено 2.1 IBExpert не показва нищо. А и навсякъде би трябвало обектите да са с тази версия.
Default character set - WIN1251 - тази и горната опция се използват по подразбиране в настройките, когато регистрирате нова база. Character set оказва влияние и върху символите, които не са на латиница, както и начина по който ще влезнат в базата данни. Така ако се пусне скрипт, който вкарва или променя нещо на кирилица в програмата може и да излезе на "маймунки", или ако се гледа на друг компютър с други настройки.
Disable multiple instances of IBExpert - това предотвратява да се пуснат по повече от 1 IBExpert. Аз съм си го включил
Restore desktop after connect - дали да запомни какво е имало отворено, при последното затваряне на базата данни и да го възстанови при нова връзка. Аз съм го спрял, че понякога като отворя по 10-на таблици и процедури, после се чака да се заредят отново. А те вече може да не ми трябват. Особено се усеща, когато базата данни не е на локалния компютър, а е някъде в интернет. Тогава чакането да се заредят таблиците и другите прозорци може да се проточи при една по-лоша връзка със сървъра.

Tools-> SQL Editor: е добре отметката Fetch All да е изключена. Ако е пуснат при отваряне на данните в някоя таблица ще се чака да извлече всички данни от нея. Това първо увеличава доста използваната памет от програмата и второ времето да се зареди таблица с няколкостотин хиляди реда или пък милион през интернет е доста голямо.

Tools->SQL Script Options - тук пуснете и двете отметки. При пускане на скрипт върху базата, ако възникне грешка, изпълнението ще спре веднага на първата, като промените няма да бъдат запазени. В противен случай, при някой по-голям и сложен скрипт, ще стане "мазало". Къде минало нещо, къде не. И времето за оправяне на базата нараства доста.

Друга полезна настройка е Allow multiselect във Grid - позволява в таблиците с данни и резултати от заявки да се маркират по повее от 1 ред, за да се прави нещо с тях.

В Associations може да си изберете кои файлови разширения директно да се отварят с IBExpert. Така като решите да регистрирате някоя база данни, вместо да я търсите по диска от диалога за регистриране - директното щракане върху нея в Explorer-a зарежда диалога за регистрация в IBExpert с данните за път, версия на сървъра и character set, които са настроени. А ако вече я има регистрирана директно я отваря в IBexpert.

И една последна опция за това кое да се показва, като се зареди таблица. По подразбиране тов е списъка с имената и типа на полетата в таблицата. Аз съм го настроил като отворя таблица и да ми показва данните в нея. Това става от Options -> Obejct Editor Options:

Tables editor - Active page избира се Data

II. Конфигуриране и използване на aliases(псевдоними)

Сега да минем към използването на Aliases във Firebird. Трябва да ви е направило впечатление, че като се връзваме към бази на нашия сървър за път до базата не се пише дълъг път с папки и имена на файлове, а е просто някаква дума. Точно тази "дума" е така наречения alias или псевдоним.
Те се конфигурират във файла aliases.conf, който се намира в главната папка на Firebird - там където е и firebird.conf. Във него псевдонимите се описват по следния начин
псевдоним = пълен път до файла
Отделните псевдоними трябва да са на отделен ред.
# в началото на реда закоментира реда и го прави неактивен. Firebird го вижда като коментар, а не като конфигуриран псевдоним.
Не е необходимо рестартиране на Firebird. Веднага след записа на файла, ако е написано правилно новите връзки към базата може да минат веднага през псевдонима.
Може да конфигурирате Firebird да дава достъп до базата данни само през псевдоним и да не може да се свързва към нея директно, като се напише файловия път.
Това става, като във firebird.conf пуснете опцията DatabaseAccess = None Тук вече е необходимо Firebird да се рестартира, за да приеме новата настройка.
Удобството на псевдонимите е, че може да се мести файла с базата данни по файловата структура на сървъра, без да е необходимо после на всички клиенти да се сменя настройката за връзка с базата. Само се слага новия път срещу псевдонима.

III. Някои разяснения относно базата данни

Тук смятам да дам някои разяснения за нещата по базата данни.
На всички се е случвало някоя програма да гръмне и да изплюе съобщение от рода на :
violation of FOREIGN KEY constraint "FK_OPR_OPR_TIP" on table "OPR" или
violation of PRIMARY or UNIQUE KEY constraint "PK_OPR_TIP_ID" on table "OPR_TIP" -
тези двете са от най-честите. Едно такова съобщение може много да помогне за да се разбере от какъв тип е проблема и къде точно е станал. Така заедно със знанието какво точно е направено в програмата в този момент, помага да се насочи за мястото, където да се търси.

В базата има няколко вида ключове - първични, вторични, уникални.
Първичните ключове се използват за генерирането на уникални номера и обикновено се записват в полето ID. Грешка в такова поле, показва, че искаме да запишем 2 еднакви стойности в такова поле.
Вторичните се използват за логическо свързване на данни между две таблици. Грешка в такъв ключ значи, че в подчинената таблица опитваме да сложим стойност, която я няма в главната.
Уникалните се използват за да се избегне повтарянето на стойност в дадено поле или комбинация от стойностите на няколко полета.
Как да разберем каква е грешката? По името.

При именоването на описаните ключове, обикновено се спазва следната схема - префикс_име_на_таблица_поле, като за всеки от тях се използва отделен префикс. Така самото име подсказа в коя таблица и кое поле е гръмнало. Всяка таблица има един първичен ключ, 0 или няколко вторични и уникални ключа.
Префиксите са PK-първичен ключ, FK-вторичен, UNQ - уникален.
Пример за PK - PK_OUT_EL_ID - PK - Показва, че ключа е първичен, за таблица OUT_EL и е върху полето ID.
FK_IN_EL_OPR_ID - това е FK-вторичен ключ, към полето OPR_ID за таблица IN_EL.

Ако вземем горната грешка:
violation of PRIMARY or UNIQUE KEY constraint "PK_OPR_TIP_ID" on table "OPR_TIP" -, тя показва, че се прави опит за дублиране на стойност в поле от таблица, където това е забранено. От префикса PK разбираме, че става въпрос за първичен ключ, а не уникален. Понеже винаги е за поле ID, OPR_TIP - остава за име на таблицата. И грешката ни показва, че в таблица OPR_TIP съм опитал да запиша една стойност два пъти. В случая след ръчно добавяне на нов запис, след като опитах да го вмъкна през конверт-а на програмата отново, ми даде грешката, че вече го има.

За грешката :
violation of FOREIGN KEY constraint "FK_OPR_OPR_TIP" on table "OPR" -
показва, че проблема е за вторичен ключ в таблица OPR, а полето, което генерира грешката е OPR_TIP.
В случая пробвах нова операция и бях забравил да я добавя в конверт-а. Така в една база, изскочи грешка, че опитвам да запиша тип на операция, която не съществува.

Друг често срещан вид грешки са тези с многото цифри - Системна грешка IBErrorCode: 335544421 да речем.
Всички грешки идващи от Firebird имат подобен номер. Някои от тях са прихванати в отделни места от програмата, но много не са. Всичките са описани във pdf файл от 30 страници. Обхващат всякакви проблеми от грешки в базата, проблеми с мрежата, проблеми с права, със структурата на файловете и т.н. За улеснение е качен и на нашия сайт : http://unrealsoft.bg/updates/f.php?path=aton/fb_2_1_errorcodes.pdf Доста често зад един такъв код се крие проблем с лесно решение, стига да се знае какво точно показва. Горния пример с 335544421 показва, че сървъра отказва връзка с клиента. Или 335544721 което показва, че не може да се открие сървъра. Това от своя страна е възможен проблем с мрежата, а не с програмата и решението е нещо, което трябва да се направи локално.

За момента е това. Ако има нещо ново, ще се дописва във първия пост, за да са на едно място нещата. Ако има нещо, което ви интересува как се прави или съм пропуснал - казвайте.
Аватар
mIRCata
Admin
 
Мнения: 1061
Регистриран на: 15-11-2004 15:25
Местоположение: Тайна майна
Име: инж. Мирослав Джоров

Назад към Общи приказки

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 1 госта

cron