Dne 1.2.2011 18:45, Zbyněk Burget napsal(a):
První průšvih nastává při vytvážení vazeb nadřízených a
podřízených zařízení. V tabulce "zarizeni" používám pro sloupeček
"zarizeniid" ovl. prvek seznam. Obsah seznamu získávám pomocí SQL[nativní]:
select nazev,zid from zarizeni union select '<žádný>',null;
Problém je, že při zápisu nového zařízení do tabulky se tento dotaz
nepřepočítá a já na toto nově vložené zařízení nemůžu navázat zařízení
jiné. Musím formulář zavřít a znovu otevřít. Přitom se znovu provede
select a vytvoří se položky seznamu. Takže první část mého dotazu je,
jak donutit seznam, aby znovu spustil SQL[native] dotaz a přepočítal
položky (asi zase není tak native, jak by se dalo čekat).
Vyrobte si formulář založený na tabulce "zarizeni" s podřízeným
formulářem založeným opět na tabulce "zarizeni". Svažte pole "zid" z
nadřízeného formuláře s polem "zarizeniid" z podřízeného formuláře. V
podformuláři se pak objeví vždy seznam všech zařízení majících za
"rodiče" právě vybrané zařízení v hlavním formuláři. Nová zařízení lze
pochopitelně dopisovat.
Váš formulář s rozbalovacím polem pak využijete v případě, že budete
potřebovat změnit rodiče již existujícího zařízení. (Jinak byste ho
musel pod původním rodičem vymazat a znovu vytvořit pod novým rodičem.)
Na stejném listu bych pak rád viděl tabulku služeb. Ale ne tak, aby se
mi ukázaly pouze služby navázané na jedno zařízení (to by byl
podformulář tabulky zařízení), ale tak, aby se ukázaly všechny služby na
technologickém místě. Nemůžu služby zobrazit jako podformulář tebulky
"mista", protože v hierarchi je mezi nimi ještě tabulka "zarizeni".
Chtěl jsem to řešit filtrem formuláře, ale nevím, jak do filtru dostat
seznam "zid", abych vyfiltroval příslušné služby.
Parametrický dotaz je jasná cesta, jen jsem nikde nenašel, jak mám
zapsat vazbu parametru na aktuální záznam v jiné tabulce. V mém případě
bych tam zřejmě potřeboval dostat obsah ovládacího prvku z formuláře.
Netuším jak se na něj odkázat (nebo se to dá udělt jinak a já nevím jak).
V režimu návrhu prostě do formuláře založeného na parametrickém dotazu
do chlívečku pro vazební pole napíšete název parametru (to za dvojtečkou
v SQL příkazu) místo názvu pole, toť vše. Zkoušel jsem to (i na
PostgreSQL) a funguje to.
Pochopil jsem správně, že můžu formulář založit na dotazu a bude
editovatelný? To by problém řešilo - protože výsledná pole dotazu budou
z jedné tabulky, pouze ve WHERE klauzuli bude select z více tabulek.
Tady ale bude zase potřeba použít parametrický dotaz, takže platí moje
neznalost propojení parametru na záznam / ovládací prvek popsaná výše.
Tohle jsem nikdy netestoval, tak nevím. Ani si nepamatuji, ve které
verzi OOo to zavedli, ale rozhodně to nebylo moc dávno. Na PoststgreSQL
to momentálně vyzkoušet nemůžu, protože se mi nechce downgradovat OOo -
viz poslední odstavec.
Pokud byste s tím nepochodil, bylo by možné ještě poupravit strukturu
databáze tak, abyste se vše odehrálo jen na vazbách mezi tabulkami.
Mimochodem, bylo by nanejvýš žádoucí definovat mezi tabulkami referenční
integrity (cizí klíče). Ty Vám nedovolí do podřízených tabulek vložit
nic, co nemá definované identifikátory v nadřízených tabulkách. Zároveň
je možno definovat kaskádování pro mazání a změny klíčových hodnot,
pokud chcete, aby se smazání řádku nebo změna klíče přenesla z nadřízené
tabulky i do podřízených tabulek. Pokud kaskádování nepovolíte, nebude
možné v nadřízených tabulkách mazat řádky a měnit klíče, pokud budou
existovat nějaké podřízené záznamy. Záleží na tom, co preferujete.
A na závěr, pokud pracujete s PostgreSQL, tak si *neinstalujte* OOo 3.3.
Učinil jsem tak a všechny tabulky mám rázem read-only, protože OOo
nevidí jejich primární indexy. Protože se mi to stalo na více
počítačích, tak to není náhoda. (A musel jsem upgradovat na novou verzi
SDBC, která se tam v někdy posledních dnech musela objevit).
Zdravím,
Jiří Spitz
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
