Odpověď

Upozornění: do tohoto tématu bylo naposledy přispěno před 120 dny.
Zvažte prosím založení nového tématu.
Jméno:
E-mail:
Předmět:
Ikona zprávy:

Ověření:
Kolik je šest plus čtyři (slovem):

Zkratky: stiskněte shift+alt+s pro odeslání nebo shift+alt+p pro prohlédnutí


Shrnutí tématu

Poslal: vandrovnik
« kdy: 09-02-2017, 19:42:36 »

Nevím, jestli to funguje i pro MySQL, ale třeba na Firebirdu by tahle situace mohla vzniknout tím, že se pro čtení z databáze použije transakce typu "snapshot" a pro znovu-načtení dat se nezahájí nová transakce.
Poslal: rholecek
« kdy: 09-02-2017, 16:32:56 »

To plně chápu, ale mám např. tento stav:
1. PC:
Query: SELECT * FROM zapujcka WHERE vraceno = 'N' a vybere mi to všechny dosud nevrácené věci

2. PC:
start transaction;
UPDATE zapujcka SET vraceno = 'A' WHERE id_zapujka = 10;
commit; (že proběhl commit mám potvrzený z logu na serveru i kontrolním selectem na serveru)

Tak po téhle operaci by první PC při opětovném spuštění SQLka neměl zobrazit řádek s ID = 10. Bohužel stále ale zobrazuje řádek s ID = 10, i když je už v DB vraceno = 'A'. Takže je otázkou, kde hledat zakopaného psa - proč se aplikace nedozví o změně dat - je to chyba aplikace, mysql.dll nebo serveru?
Proto ta volba xiDirtyread a snad se mi to podaří v budoucnu opravit.
Poslal: pf1957
« kdy: 09-02-2017, 14:28:00 »

Díky za nakopnutí.
Změnil jsem xiReadCommitted na xiDirtyRead a funguje to.
Zaráží mě jen, že to v jedné aplikaci funguje správně a ve druhé se to chová jak chce. Teď už bude stačit přijít na to, jestli za to může aplikace nebo DB server.
Tebe by melo zarazet neco jineho: ze kdyz ti nefunguje xiReadCommited, tak to znamena, ze ta data nemas commited a tudiz tam mas bordel v transakcnim zpracovani. Pouzitim xiDirtyRead v podstate likvidujes izolaci transakci navzajem a hrabes se nekomu jinemu v neukoncene transakci, ktera nakonec muze byt zahozena (odrolovana zpatky). A pro neco takoveho uz musis mit normalne setsakra dobrej duvod...
Poslal: Stanislav Hruška
« kdy: 09-02-2017, 14:19:47 »

Citace
Zaráží mě jen, že to v jedné aplikaci funguje správně a ve druhé se to chová jak chce.
To si nemyslím. Oni tie transakcie na sebe závisia. Ak jedna transakcia nepovolí iným vidieť zmeny, tak ich nevidia.
Poslal: rholecek
« kdy: 09-02-2017, 14:12:44 »

Díky za nakopnutí.
Změnil jsem xiReadCommitted na xiDirtyRead a funguje to.
Zaráží mě jen, že to v jedné aplikaci funguje správně a ve druhé se to chová jak chce. Teď už bude stačit přijít na to, jestli za to může aplikace nebo DB server.
Poslal: Stanislav Hruška
« kdy: 09-02-2017, 13:47:27 »

Predpokladám, že to je spôsobené nastavením Transaction.Isolation. Máš tam asi 6 druhov.
Poslal: rholecek
« kdy: 09-02-2017, 13:39:08 »

Mám DB aplikaci, která čte data z MySQL pomocí FireDac query.
Při prvním spuštění SQL to načte data, které odpovídají podmínce.
Pokud dojde ke změně těchto dat (jinou aplikací jiným uživatelem na jiném počítači včetně commitu),
tak při opětovném spuštění SQL dotazu to načte původní data - nevidím změněná data.
Pokud potřebuji opravdu načíst nová data, musím ukončit a opětovně spustit aplikaci.
Je zvláštní, že to někdy funguje bez problémů (normálně to při opětovném spuštění stejného SQL načtě změněná data).
Nesetkal se někdo s něčím podobným?