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

[vandrovnik]

Mimochodem, proč nepoužiješ parametry? Pak se člověk podobnými radostmi nemusí zabývat. Nemluvě o tom, že tenhle problém sice asi nějak vyřešíš, ale nevíš, jaká další zrada tam číhá - apostrofy? Nějaký escapovací znak? Dva takové znaky za sebou? ...

[IBAG2008]

Parametry bych použil rád, ale mám jen replikační log v souboru.
Je to fungující proces, do kterého bych nerad zasahoval akorát občas tam vyskočí něco podobného - v nové plánované verzi už jsou parametry.

Pomohlo ten odkaz co psal Delfín a na něm:
For '!', '&', '{', '}, set ResourceOptions.MacroCreate, MacroExpand and EscapeExpand to False.

Pak se neprovádí při načtení do komponenty žádná změna SQL a vše funguje.

díky za vyřešení Z.

[Stanislav Hruška]

Zdrojem je textovy replikacni log, bohuzel je to pouze cisty sql bez parametru.

Ja som síce amatér, ale také niečo by som do svojho programu nedal. Mám tým na mysli výsledok. Z môjho pohľadu je to veľmi horúce miesto na prepracovanie. Ale či sa to dá

Radost uz vyplyva z faktu ze je ten SQL prikaz zadavan v IDE.

Toto som radšej ani nespomínal. Vidieť obsah tabuliek DB v zdrojáku je... no, na zvracanie.

[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.

[Stanislav Hruška]

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

[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.

[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äť