Umíme to s Delphi: 88. díl – BDE: co se souborem PDOXUSRS.NET?

Dnešní díl seriálu navazuje na popis praktického používání databázové platformy BDE: její uživatelé mají často noční můry ze souboru PDOXUSRS.NET, který se sveřepě vytváří v adresáři C:\. Co si počít v případě, kdy nám tento adresář nevyhovuje, případně je-li nepřístupný? Kromě odpovědí přináší dnešní článek také popis komponenty Session sloužící ke globální správě více databázových připojení.
Před týdnem se náš seriál zabýval otázkou, jak používat databázovou aplikaci používající BDE na počítači, na němž nikdy nebylo instalováno Delphi ani BDE. Vysvětlili jsme si, že je nutné zahrnout BDE modul do tvorby instalačního balíku.

Uživatelé BDE mají však i další otázky: jednou z nejčastějších je soubor PDOXUSRS.NET, který je vytvářen při použití paradoxových tabulek na disku C:\. Tento adresář je někdy nevhodný, jindy přímo nepoužitelný (např. nemáme-li k němu dostatečná práva pro zápis). Naštěstí i tento problém lze obejít – stačí vědět, jak na to.

Ještě před tím si však dovolím krátkou odbočku. Vždycky, když na Živě vyjde článek týkající se technologie BDE, obdržím dvě skupiny emailů. V první skupině se píše: „proč pořád píšeš o BDE, když je to zastaralé, pomalé a na ústupu?“ Druhá skupina naopak děkuje za informace o BDE a táže se: „používáme ve firmě už * let BDE a teď nám postavili novou síť a aplikace neběhají. Co s tím?“

Osobně chápu obě skupiny tazatelů. Pro první z nich je přirozené, že je-li něco zavrženo a nahrazeno lepší novinkou, nemá smysl se v tom dále rýpat. Druhá skupina naopak používá spokojeně starou verzi a pro přechod na novou nemá ani ten nejmenší důvod.

Jak známo, běžní uživatelé jsou konzervativní. Sám jsem stejný – pokud něco funguje, postačuje a vyhovuje, není důvodu to měnit. Zavádět novou technologii jen proto, že vznikla, nemá smysl. Přesně z téhož důvodu existuje stále mnoho a mnoho uživatelů používajících BDE. Tito uživatelé mají řadu praktických otázek a já věřím, že mají stejné právo získat na ně odpovědi, jako uživatelé novinek. Proto se pokouším v seriálu popisovat vedle novějších i starší koncepce. Nikoliv proto, že neexistuje novější alternativa, ale z toho důvodu, že uživatelů stávající verze je velké množství.

Tolik na vysvětlenou pro ty, kteří netrpělivě očekávají konec „ságy BDE“. Věřím, že ještě dnešní díl přežijí. Od příštího týdne se pak budeme konečně věnovat něčemu jinému.

Co se souborem PDOXUSRS.NET?

Častý čtenářský dotaz zní, co si počít se souborem PDOXUSRS.NET. Dovolím si ocitovat jeden z dotazů na toto téma:

Když v Delphi vytvořím paradoxové tabulky, tak se mi na C:\ vytvoří soubor PDOXUSRS.NET. Předpokládám, že se tam ukládají nastavení ohledně těch tabulek, blokování přístupových práv apod. Ale jak se toho zbavit tak, aby byla vytvořená aplikace přenositelná? Problém je například v momentě, kdy potřebuji aplikaci použít na počítači, který má zakázaný zápis na C:\. Co používat jiného místo paradoxových tabulek (ale tak, aby byla aplikace přenositelná pouhým překopírováním .exe + tabulek, tj. aby se nemusely vytvářet ODBC linky apod)? Případně jak přenastavit paradoxové tabulky tak, aby se soubor PDOXUSRS buď vůbec nevytvářel nebo aby se automaticky vytvářel v adresáři, ve kterém je .exe a tabulky?

Především je nutné zdůraznit, že nelze dosáhnout toho, aby byla databázová aplikace přenositelná pouhým překopírováním souboru *.exe a tabulek. Jde o to, že aplikace nikdy nepracuje přímo s databázovými tabulkami: přístup k těmto tabulkám zajišťuje obvykle Borland Database Engine. K tomu, aby databázová aplikace běžela, je tedy potřeba soubor exe, tabulky, a pak stroj BDE, který data z tabulek zpřístupní exe souboru.

Proto zkopírování tabulek a exe souboru nemůže stačit. V každém případě je nutné na cílový počítač nějak „dostat“ i databázový stroj. A to neplatí jen o BDE, ale o každé databázové aplikaci. Je nutné si uvědomit, že při vytvoření databázové aplikace se dostáváme za hranice, u nichž k běhu programu stačí jeden spustitelný soubor. Chceme-li data z databáze, musíme nějakou databázi mít. Pokud na cílovém počítači dosud není, musíme zajistit, aby se tam ocitla. Jeden ze způsobů, jak dostat „BDE“ na cílový počítač, jsme si vysvětlili v předchozím článku – řešením je vytvořit instalační balík a zaškrtnout modul BDE_ENT.

A nyní k druhé části dotazu – co se souborem PDOXUSRS.NET?

Rozhodneme-li se používat v databázové aplikaci paradoxové tabulky, máme k dispozici dvě proměnné, s nimiž můžeme (a někdy dokonce musíme) pracovat. První se jmenuje NetFileDir, druhá PrivateDir.

Proměnná NetFileDir specifikuje adresář, který obsahuje tzv. „Paradox network control file“, což je právě soubor PDOXUSRS.NET. Účelem tohoto souboru je kontrola a správa paradoxových tabulek v síťovém prostředí. Všechny aplikace, které hodlají sdílet příslušné paradoxové tabulky, musí specifikovat tentýž adresář, v němž je uložen soubor PDOXUSRS.NET: typicky se jedná o adresář na síťovém souborovém serveru. Delphi přebírá hodnotu proměnné NetFileDir z konfiguračního souboru Borland Database Engine. Jinak řečeno – BDE ukládá informaci o umístění PDOXUSRS.NET pro každý registrovaný databázový alias a při použití příslušného aliasu v Delphi je hodnota vlastnosti NetFileDir nastavena podle příslušného záznamu v konfiguraci aliasu v BDE.

Kromě toho je ovšem možné nastavit NetFileDir ručně. Nastavená hodnota samozřejmě překryje hodnotu získanou z BDE, proto je nutné dbát při změnách NetFileDir určité opatrnosti.

Nyní si ukážeme, jakým způsobem nastavit hodnotu NetFileDir v návrhové fázi. Postup je jednoduchý: stačí použít Object Inspector. NetFileDir (stejně jako PrivateDir) jsou vlastnosti komponenty Session, přesto však není nutné tuto komponentu na formulář vkládat (jak si ukážeme dále). Pro jednoduchost a pro názornost ji však nyní použijeme – nalézá se v záložce BDE. Pak již nastavíme vlastnost NetFileDir přímo v Object Inspectoru.

Za běhu aplikace je změna stejně jednoduchá, jako změna jakékoliv jiné vlastnosti. Opět je vhodné použít komponentu Session. Následující příkaz nastaví hodnotu NetFileDir na adresář, z něhož byla spuštěna aplikace:

  Session.NetFileDir := ExtractFilePath(Application.EXEName);

O několik odstavců níže si celý postup (včetně použití komponenty Session) ukážeme prakticky.

Ještě předtím však jedna poznámka: vlastnost NetFileDir může být změněna pouze v případě, že aplikace zrovna nepracuje s žádnými paradoxovými tabulkami (žádné tabulky nejsou otevřené).

K čemu je vlastnost PrivateDir?

Přestože vlastnost PrivateDir komponenty Session se bezprostředně netýká souboru PDOXUSRS.NET, nyní je myslím vhodný okamžik i k jejímu stručnému vysvětlení.

PrivateDir specifikuje adresář pro ukládání dočasných souborů s tabulkami a s dalšími informacemi, napříkald soubory generované BDE za účelem práce s lokálními SQL dotazy. Pokud do PrivateDir nenastavíme žádnou hodnotu, BDE automaticky použije aktuální adresář (přesněji řečeno – použije se adresář, který je aktuální v okamžiku, kdy se BDE inicializuje).

Co z toho plyne? Pokud používáme aplikaci i BDE na lokálním počítači s lokálním diskem, nemá smysl se s PrivateDir nijak zaobírat a je vhodné ponechat implicitní nastavení. Pokub byste se ovšem dostali do situace, v níž aplikace běží např. přímo na síťovém serveru, je možné částečně zlepšit její výkon tím, že před otevřením databáze nastavíte hodnotu PrivateDir na lokální (uživatelův) počítač.

Pozor: PrivateDir nastavujte raději výhradně za běhu aplikace (v run-time). Změníte-li ji v návrhové fázi (v Object Inspectoru), dojde při spuštění aplikace ve většině případů k hlášení výjimky „Directory is busy“. V žádném případě se také nedoporučuje nastavovat PrivateDir na kořenové adresář, vždy použijte raději podadresář.

Následující řádka je ukázkou nastavení PrivateDir za běhu aplikace:

  Session.PrivateDir := `C:\TEMP`;

Ukázka práce s NetFileDir a s PrivateDir

Nyní pojďme společně vytvořit jednoduchou aplikaci, na níž si ukážeme způsob práce s vlastnostmi NetFileDir, PrivateDir a s komponentou Session vůbec.

Předpokládejme, že máme v BDE definovaný alias pro nějakou databázi používající paradoxové tabulky. Pokud nevíte, jak to provést, přečtěte si prosím 78. díl tohoto seriálu; najdete v něm podrobný popis celé operace.

Pro jednoduchost nebudeme používat datový modul a všechny komponenty umístíme přímo na formulář. Raději zdůrazním, že správná architektura aplikace by vyžadovala použití datového modulu (podrobný popis viz 75. díl seriálu), aby se oddělily komponenty uživatelského rozhraní od komponent pracujících s daty a s databází.

1. Vytvořte novou aplikaci, na formulář vložte komponenty Table a Session ze záložky BDE, dále komponentu DBGrid ze záložky DataControls a dále komponentu DataSource ze záložky Data Access.

2. Nastavte vlastnost DataSet komponenty DataSource na hodnotu „Table1“.

3. Nastavte vlastnost DatabaseName komponenty Table na zvolený databázový alias (vyberte z rozbalovacího seznamu v Object Inspectoru).

4. Nastavte vlastnost TableName komponenty Table na zvolenou databázovou tabulku (vyberte z rozbalovacího seznamu v Object Inspectoru).

5. Nastavte vlastnost Active komponenty Table na True.

6. Nastavte vlastnost DataSource komponenty DBGrid na hodnotu „DataSource1“ (vyberte z rozbalovacího seznamu v Object Inspectoru).

7. Nyní si „pohrajeme“ s komponentou Session. Nejprve je nutné nastavit vlastnost SessionName. Vyplníme například „Session“. Poté si zkuste nastavit vlastnost Active této komponenty na True. Všimněte si, že se okamžitě automaticky vyplnily hodnoty vlastností NetFileDir a PrivateDir – hodnoty byly získány z konfigurace příslušného aliasu v BDE. Nic nám ovšem nebrání změnit například NetFileDir. V Object Inspectoru tedy zadejte jiný adresář.

8. Zkuste si aplikaci přeložit a spustit. Všimněte si, že v adresáři, který jste zadali do NetFileDir, došlo k vytvoření PDOXUSRS.NET.

9. Připomínám, že vlastnost PrivateDir bychom neměli měnit v Object Inspectoru, ale výhradně za běhu programu.

Další možnosti komponenty Session

Předchozím povídáním jsme se dostali ke komponentě Session, která je pro nás dosud neznámou – v žádném z předchozích dílů jsme se jí rozsáhleji nezabývali. Jedná se však o zajímavou komponentu, která nám dokáže zpřístupnit celou řadu informací a možností, proto se na ni v krátkosti zaměříme dnes.

Nejprve obecný popis – komponenta Session poskytuje nástroje pro globální správu skupiny databázových připojení v aplikaci. Používá se v případě, kdy potřebujeme spravovat více databázových připojení v rámci jedné aplikace.

Komponenta je definována v jednotce DBTables. Pokud tuto knihovnu vložíme do aplikace (do sekce Uses), nemusíme již na formulář vkládat komponentu Session – knihovna automaticky vytvoří globálně přístupnou („default“) komponentu Session pojmenovanou Session. Proto po vložení knihovny můžeme ihned používat objekt Session (nastavovat jeho vlastnosti, volat metody apod.).

Pokud databázová aplikace potřebuje např. paralelně pracovat s různými paradoxovými tabulkami umístěnými v různých síťových lokacích, není problém vytvořit více sessions, jednu pro každou lokaci.

Sessions je nutné používat také v případě vícevláknových databázových aplikací. Pokud používáme v aplikaci více komponent Session, můžeme je ovládat centralizovaně pomocí komponenty TSessionList. Stejně jako u komponenty Session, i v případě SessionList vytvoří knihovna automaticky jednu default instanci, která je nazvána Sessions (pozor na koncové „s“).

V následujícím přehledu si ukážeme, jaké všechny informace můžeme získat o sessions. Slouží k tomu informační metody.

Metoda Význam
GetAliasDriverName Zjistí a vrátí informace o BDE ovladači pro příslušný databázový alias.
GetAliasNames Zjistí a vrátí informace o všech dostupných BDE aliasech.
GetAliasParams Zjistí a vrátí seznam parametrů pro příslušný BDE alias.
GetConfigParams Zjistí a vrátí konfigurační informace z konfiguračního souboru BDE.
GetDatabaseNames Zjistí a vrátí seznam všech BDE aliasů a všech komponent TDatabase, které jsou aktuálně používány.
GetDriverNames Zjistí a vrátí informace o všech aktuálně nainstalovaných BDe ovladačích.
GetDriverParams Zjistí a vrátí seznam parametrů pro zadaný BDE ovladač.
GetStoredProcNames Zjistí a vrátí informace o všech uložených procedurách pro zadanou databázi.
GetFieldNames Zjistí a vrátí informace o všech polích v zadané tabulce v zadané databázi.

Většina metod vrací informace ve formě seznamu (TStrings). Použití je proto velmi jednoduché a ukážeme si jej v následujícím výpisu. Předpokládejme, že je na formuláři komponenta ListBox, do níž chceme vypsat názvy všech definovaných BDE aliasů. Pak napíšeme:

procedure TForm1.Button1Click(Sender: TObject);
begin
  Session.GetAliasNames(ListBox1.Items);
end;

Po klepnutí na tlačítko se ihned v ListBoxu zobrazí příslušný seznam aliasů, viz obrázek:

Na závěr

Dnešní díl seriálu se pokusil odpovědět na další častý uživatelský dotaz týkající se BDE. Protože však nejen BDE živ je databázista, příští díl bude už věnován jiné, pokrokovější databázové platformě. Vysvětlíme si, jak v Delphi pracovat s databází Interbase/Firebird. Pokud se však časem sejdou další náměty týkající se databáze BDE, jistě se k této zastaralé, avšak stále hojně používané technologiemi vrátíme.

Diskuze (3) Další článek: I instant messaging potřebuje šifrování, říká PGP

Témata článku: , , , , , , , , , , , , , , , ,