chyba při provádění SQL na Firebirdu přes komponentu TFDQuery

[pf1957]

Pokud odstraním uvozovky tak to projde v pořádku.

Tohle nema co delat s validovanim ale s nezbytnym porozumenim strukture SQL dotazu - to delaji kazde komponenty, protoze kdyz jim strcis nejaky string a kterem prohlasujes, ze je to SQL prikaz, tak si ta komponenta musi zjistit jaky (vraci/nevraci result set, ma parametry apod.).

Resenim je samozrejme vyhnout se nejak obskurne sestavovanym SQL prikazum a pouzit parametry, jak jiz bylo napsano.

[Stanislav Hruška]

Ešte by ma zaujímalo odkiaľ ten replikačný log ťahá údaje. Lebo ak z DB, tak by podľa môjho názoru mal vrátiť platný Select.

[Delfin]

Resenim je samozrejme vyhnout se nejak obskurne sestavovanym SQL prikazum a pouzit parametry, jak jiz bylo napsano.

To rozhodne. Je totiz treba mit na pameti, ze se zapnutymi makry se i z vhodne uvozeneho konstantniho retezce, jako napr.:

Kód: MySQL [Vybrat]

1. INSERT INTO MyTable (TheColumn) VALUES ({s Itchy&Scratchy});

muze stat makro s nazvem Scratchy diky symbolu & jenz uvozuje substitucni promennou.

Ešte by ma zaujímalo odkiaľ ten replikačný log ťahá údaje. Lebo ak z DB, tak by podľa môjho názoru mal vrátiť platný Select.

To vrati. Ale ta zminovana vyjimka byla vyvolana FireDAC parserem preprocesoru (jenz parsuje predany retezec dotazu jeste pred pripravou SQL prikazu pripojenym DBMS).

[Stanislav Hruška]

Ja som to myslel takto: UPDATE OR INSERT INTO PREPRAVA SELECT....

[Delfin]

Ja som to myslel takto: UPDATE OR INSERT INTO PREPRAVA SELECT....

A jak bys resil replikaci na jiny server? Umi Firebird linkovane servery?

[IBAG2008]

U offline replikací je důležité aby se měnila data v přesně stejném pořadí jak vznikal insert/update/delete, aby na to mohli reagovat
triggery na cílové DB, takže je důležité mít replikační sql v době vzniku a následný select z dat by to neřešil.
Proto je v replikačním logu již hotové SQL.

Potřeboval jsem pouze to, aby komponenta nemodifikovala dále sql příkaz a s tím jste mi pomohli.
SQL byl v IDE zadán pouze pro ověření jestli bude už komponenta hlásit chybu, bez toho že by se příkaz prováděl na cílové DB.

Z.

[Delfin]

Potřeboval jsem pouze to, aby komponenta nemodifikovala dále sql příkaz a s tím jste mi pomohli.

Ted jde o to, zda takove chovani FireDAC nepovazovat za chybu. Podle me by se mohly substitucni promenne chovat stejne jako escape sekvence (jenz se aplikuji jen pokud nejsou uvnitr konstantniho retezce prikazu).

[vandrovnik]

U offline replikací je důležité aby se měnila data v přesně stejném pořadí jak vznikal insert/update/delete, aby na to mohli reagovat triggery na cílové DB, takže je důležité mít replikační sql v době vzniku a následný select z dat by to neřešil.
Proto je v replikačním logu již hotové SQL.

Tohle řeším tak, že pro importy/exporty se naopak triggery neprovádějí vůbec (že se jedná o import/export se pozná podle role pro připojení). Změny, které se v databázi udály kvůli spuštění triggeru, se do ostatních databází přenesou samostatně. Ale zachovat pořadí je rozhodně důležité mj. kvůli referenční integritě.

[Stanislav Hruška]

Ďakujem za vysvetlenie o čo ide. Ja sa hrám na svojom piesočku a často zabúdam, že okolo toho piesku existuje úplne iný svet. Ten ani nepoznám. Takže tie slová o zvracaní beriem späť