[Delphi, Interbase] Algemene vraag over db componenten

[Verwijderd]

Ik zou graag willen weten hoe jullie het volgende doen en wat de beste methode hiervoor is.

Ik werk met Interbase/Firebird en gebruik de IBX componenten.

Nu heb bij een project een DataModule waarop ik een Database componentje plaats met een daarbij horende transactie componentje. Verder heb ik een X aantal query componentjes met ook ieder een eigen transactie component.

Het probleem met deze constructie is dat je goed moet oppassen dat procedure A een bepaald type query component gebruikt en dat binnen procedure A geen andere procedure's aangeroepen worden die ook gebruik maken van diezelfde query.

Daarom vraag ik me af of het niet beter is om gewoon alle query componentjes dynamisch aan te maken tijdens runtime. Dus dat iedere procedure zijn eigen query en transactie component aanmaakt en bij het verlaten van die procedure weer vrijgeeft.


Een ander voordeel hiervan is dat je steeds begint met een nieuwe transactie. Als je nu een bepaald query component tijdens designtime aangemaakt heb en die vervolgens overal gebruikt, moet je er goed voor zorgen dat die wel steeds de transactie rollbackt of commit. (Nu heb ik dus overal waar een error ontstaat tijdens een query actie in de exception staan, dat die de transactie moet rollbacken). Als je dat niet zou doen, zou je geen gewijzigde gegevens meer zien.

Kortom graag hoor ik jullie mening over wat nu het beste is.

[whoami]

Verwijderd schreef op 19 augustus 2003 @ 20:54:

Een ander voordeel hiervan is dat je steeds begint met een nieuwe transactie.

Is dat een voordeel?
Je moet natuurlijk je transactions zo kort mogelijk houden, maar je moet wel de 'taken' die op de data werken en logisch gezien bij elkaar horen in dezelfde transactie houden.

Als je bv. een procedure schrijft die geld overschrijft van rekening A naar rekening B, dan ga je de update op tabel A en die op tabel B in dezelfde transactie zetten. Anders hebben transacties geen nut.

[Verwijderd]

Ja dat over die transacties daar heb je idd gelijk in. Ik doe dat nu verkeerd.

Maar stel je hebt procedure A waarin je een select uitvoert met query A. Vervolgens loop je het query resultaat door en roep je per record een andere procedure aan die ook gebruik maakt van een query. Je moet dan natuurlijk goed in de gaten houden dat je daar niet query A voor gebruik.

Dat is de rede waarom ik dacht dat het misschien beter is om die query componenten dynamisch in die procedure aan te maken.

Maar hoe doe jij het precies?

[whoami]

Verwijderd schreef op 19 August 2003 @ 21:39:
Ja dat over die transacties daar heb je idd gelijk in. Ik doe dat nu verkeerd.

Maar stel je hebt procedure A waarin je een select uitvoert met query A. Vervolgens loop je het query resultaat door en roep je per record een andere procedure aan die ook gebruik maakt van een query. Je moet dan natuurlijk goed in de gaten houden dat je daar niet query A voor gebruik.

Kan je die 2 queries dan niet combineren tot 1 query (dmv een join).
Of kan je die zaken niet doen dmv stored procedures?

Voor gewone selects heb je geen transactions nodig trouwens. Die heb je enkel nodig voor INSERT/UPDATE en DELETE statements.

Maar hoe doe jij het precies?

Daar kan ik geen antwoord op geven, want jouw uitleg is nogal abstract.

[Verwijderd]

whoami schreef op 19 August 2003 @ 21:41:Kan je die 2 queries dan niet combineren tot 1 query (dmv een join). Of kan je die zaken niet doen dmv stored procedures?

Je moet dan denken aan dat je 1 query heb waar je een select mee heb uitgevoerd en aan de hand van die waarden, maak je dan wijzigingen in een andere tabel bijvoorbeeld.

Voor gewone selects heb je geen transactions nodig trouwens. Die heb je enkel nodig voor INSERT/UPDATE en DELETE statements.

Iedere actie vindt toch plaats binnen een transactie dus ook een select?

[whoami]

Verwijderd schreef op 19 August 2003 @ 21:53:
[...]
Je moet dan denken aan dat je 1 query heb waar je een select mee heb uitgevoerd en aan de hand van die waarden, maak je dan wijzigingen in een andere tabel bijvoorbeeld.

Dat kan je dan nog mooi met één query doen (met subqueries), of dmv een:

code:

UPDATE tabel
SET waarde = bla.waarde
FROM bla where ...

Je DBMS moet dergelijke update-constructie dan natuurlijk wel ondersteunen.

Daarnaast kan je nog altijd gebruik maken van een Stored Procedure als bovenstaande opties niet afdoende zijn.

Iedere actie vindt toch plaats binnen een transactie dus ook een select?

Een SELECT gaan geen data wijzigen, dus hoef je die ook niet te kunnen rollbacken.
(Het kan wel zijn dat Delphi ook rond een SELECT impliciet een transaction gaat zetten, maar dat weet ik niet zeker en betwijfel ik ook.)

[Verwijderd]

whoami schreef op 19 augustus 2003 @ 21:56:Een SELECT gaan geen data wijzigen, dus hoef je die ook niet te kunnen rollbacken.
(Het kan wel zijn dat Delphi ook rond een SELECT impliciet een transaction gaat zetten, maar dat weet ik niet zeker en betwijfel ik ook.)

Ja ik heb net nog ff een test gedaan en na het open van de query is er direct een transactie actief.

[alienfruit]

Goed punt hier, alienfruit gaat hier even wat wijzigen doorvoeren in zijn DB Driver

[ Voor 9% gewijzigd door alienfruit op 20-08-2003 01:29 ]