FireDAC - TFDStoredProc - defaultní hodnota parametru

[ondra.pillar]

Ahoj,

máme XE10.3.3 + FD + MSSQL. Při vykonávaní st. procedur používám TFDStoredProc s relativně defaultním nastavením. Po nastavení názvu procedury a nahození PREPARED = TRUE si FD automaticky přes metadata stáhne parametry. Potud je vše ok.
Problém je ovšem s defaultní hodnotou parametrů těch stored proc.
Pochopil jsem z profileru, že FD ty parametry pošle vždy všechny bez ohledu na to, jestli jsou NULL a MSSQL server potom ty NULL bere jako validní vstup a nepoužije ty defaultní (tomu se asi není co divit).
Ve svém zkoumání jsem ještě zjistil, že ADO to dělá stejně (taky stáhne a posílá celý param list), ale každý parametr má ještě property Attributes tam se dá odškrtnout NULLABLE a potom pošle TADOStoredProc ten parametr s hodnotou "default" a MSSQL už jede OK.
Možnost toho, že ty parametry nebudu stahovat automaticky ale manuálně je v kodu doplňovat bohužel zatím nepřipadá v úvahu.
Zkoušel jsem taky ten param list procházet, hledat NULL a ty odstranit, to zase působí chybu protože ta StoredProc už je prepared a brání se potom tomu.
SOS možnost je dát té TFDStoredProc prepared := false, odebrat FetchOptions.Items := FetchOptions.Items - [fiMeta], dát prepared znovu a ty parametry tam ručábo nacpat, ale do toho se mi nechce tak se první ptám :-)

díky za rady a nápady.

[ondra.pillar]

Tak edit,
zavolat toto nakonec pomohlo a nebylo to složité, ale přesto bych ocenil, kdyby někdo věděl nějaké elegantnější řešení

Kód: [Vybrat]

....
Prepare := false;
FetchOptions.Items := FetchOptions.Items - [fiMeta]
// projet vsechny parametry a vybrat /vymazat/ ty, ktere jsou null
Prepare := true;
....


[Jan Fiala]

Tohle je cesta, pokud ti nevadí, že se procedura vlastně spouští 2x. I ADO poprvé spustí proceduru nebo dotaz 2x, jednou, aby si stáhlo parametry a následně ji teprve vykoná. Všechna další spuštění z ADO, pokud se příkaz nemění jdou už pak jen jednou.
U kritičtějších operací a většího počtu parametrů je to pak znatelné zdržení, zvlášť na pomalejší síti - třeba když s klientem jedeš vůči serveru přes internet a VPN.

Vzhledem k tomu, že do budoucna můžeš změnit klienta, měl bys mít ošetřeno v proceduře, které parametry jsou povinné a pokud nepošleš vše, mělo by to skončit chybou z procedury s hlášením, že jsi neposlal nějaký parametr.

[pf1957]

Vzhledem k tomu, že do budoucna můžeš změnit klienta, měl bys mít ošetřeno v proceduře, které parametry jsou povinné a pokud nepošleš vše, mělo by to skončit chybou z procedury s hlášením, že jsi neposlal nějaký parametr.

Souhlasim, v podstate nevhodny navrh. RDMBS maji nullable typy, takze bud ten parametr je povinny a musim ho uvest a nebo propaguju ev. testuju hodnotu NULL. Samozrejme nejake zaboxovani v modernim jazyku s podporou nullable typu jako C# to osetri na urovni prekladu klienta, takze neni treba cekat na run-time chybu.

[ondra.pillar]

Tohle je cesta, pokud ti nevadí, že se procedura vlastně spouští 2x. I ADO poprvé spustí proceduru nebo dotaz 2x, jednou, aby si stáhlo parametry a následně ji teprve vykoná. Všechna další spuštění z ADO, pokud se příkaz nemění jdou už pak jen jednou.
U kritičtějších operací a většího počtu parametrů je to pak znatelné zdržení, zvlášť na pomalejší síti - třeba když s klientem jedeš vůči serveru přes internet a VPN.

Vzhledem k tomu, že do budoucna můžeš změnit klienta, měl bys mít ošetřeno v proceduře, které parametry jsou povinné a pokud nepošleš vše, mělo by to skončit chybou z procedury s hlášením, že jsi neposlal nějaký parametr.

Díky za odpověď,
No jasně, že mi to vadí více-méně "principiálně", protože nemám rád tyhle quick'n'diry solution. Respektive se to ke mě dostalo jako požadavek, že po přechodu na FD se děje toto :-/ a zarazilo mě, že FD pošle vždy všechno, ale jak nad tím víc a víc přemýšlím tak mi to přijde jako bezpečnější postup

[Jan Fiala]

Samozrejme nejake zaboxovani v modernim jazyku s podporou nullable typu jako C# to osetri na urovni prekladu klienta, takze neni treba cekat na run-time chybu.

Spíš jde do budoucna o případ, kdy třeba serverovou stranu bude dělat jeden člověk a klienta jiný. Nebo upravíš něco na proceduře - jeden parametr začne být povinný a na klienta zapomeneš, protože do toho budeš mít spoustu telefonů nebo něco akutnějšího. Hůř se to hledá, než když ti po spuštění procedura oznámí, že jsi neposlal parametr ten a ten.

[pf1957]

Spíš jde do budoucna o případ, kdy třeba serverovou stranu bude dělat jeden člověk a klienta jiný. Nebo upravíš něco na proceduře - jeden parametr začne být povinný a na klienta zapomeneš, protože do toho budeš mít spoustu telefonů nebo něco akutnějšího. Hůř se to hledá, než když ti po spuštění procedura oznámí, že jsi neposlal parametr ten a ten.

To je souhrnne udrzovatelnost SW - tohle pokrejes tim, ze se zbavis tech deklaratornich default hodnot.

Ale jde o dalsi uroven: jestli volas SP s ruznou sadou parametru, tak nejspis z nekolika ruznych mist, takze je vyhodne, pokud ma jazyk prostredky, jak to zkontrolovat v dobe prekladu a nenechavat to az na ladeni/testovani - ostatni to je hlavni motivace k zavedeni silne typove kontroly. A tady je Delphi bohuzel k nicemu.