naravno da moze... :)

Otprilike svaka SQL baza resava transakcije na svoj nacin, a vecina njih se opredeljuje za pojam "isolation level", pod kojim se smatra nesto kao izolacioni nivo (ne)zavisnosti izmedju razlicitih zahteva nad bazom/tabelom a nad istim podacima (tabele, redove u njima i cak kolone). Recimo AnyWhere ima 5 izolacionih nivoa, gde se zavisno od problematike promena setuje jedan od njih da je aktuelan, a dalje radis kao da si sam nad bazom, ne brines vise ni ocemu... Dakle poenta je apstrahovati poroblem i ne zamarati mnogo sa detaljima o kojoj se tabeli radi, sto je mnogo MNOGO lepo i olaksavjuce i... ma svaka im cast na pristupu; ko se baktao sa "rucnim" zakljucavanjem tabela, zna kolika to muka ume da bude...

Napominjem da problematika nimalo nije naivna, da postoji sledeca zbirka problema: Lost updates, Dirty reads, Non-reproducible reads, Phantom rows, Update side effects - bar onako kako ih je klasifikaovao IB tj. FB... (a sasvim su lepo to odradili).

IB/FB su pokusali da uvedu malo smislene sematike medju te nivoe, pa su ih nazvali prigodnim imenima: SNAPSHOT, SNAPSHOT TABLE STABILITY, READ COMMITED plus jos neke odrednice tipa: PROTECTED READ, PROTECTED WRITE, SHARED READ, SHARED WRITE...

Koncep je sledeci: moras dobro poznavati sta koji nivo izolacije posledicno znaci i moras dobro razumeti svoj problem, pa na osnovu toga odrediti nivo izolacije medju transakcijama koje se potencijalno sudaraju. Najbolje je taj problem imati u vidu vec pri samoj arhitekturi tabela: kasnije se ta "preuranjena" briga jako lepo vrati u pozitivnom smislu i za tebe koji to radis, a pogotovo za korisnike koji nemaju ono cuveno ne-da-boze: "Transakcija nije uspela, pokusajte opet ili se vratite za jedan korak u nazad..."

*

Dakle - treba iscitati jako detaljno SVE o transakcijama... i naravno, imati dve masine koje simuliraju probleme ili dva istovremena boot-a na jednoj pa navali na testove :)

(izvini sto ti nisam mnogo/konkretno pomogao)

To sam otprilike shvatio ali sam vidio da u IBAccess-u (programčić za pristup firebird bazi, kreiranje tabela i slično) mogu birati isolation level i zahtjev za lock-om određene tabele što bi meni i trebalo ali ne znam kako da to postignem koristeći IBX komponente.

Gde si to video rad sa transakcijama u IBAccess-u?

E sada, "skoro" svaka baza podrzava neki vid locking-a, one baze koje ustvari nisu baze (mysql, flashfiller itn ... ) podrzavaju table level locking. Table level locking je najidiotski moguci nacin da garantiras ACID podataka. Prave baze koriste ROW level locking, t.j. samo recorde koje se update-uju se automatski zakljucaju. U principu u FB ne mozes nista uraditi bez transakcije. Jedino sto je malo jednostavnije je kada uradis insert onda dobijes implicitnu transakciju.

Ako koristis IBX, kad postavi IBTransaction, samo double click na ikonicu na formi i dobijes dijalog da izbor izolacije transakcije. Sa prvog pa prema dole, izolation level ti je sve vise serijaliziracki. Read-Write stability == SERIALIZIBLE.

Za Riste Pejov:

Hvala

Za ultraKeen:

Konektujem se na bazu. Izaberem jednu tabelu, iz menija izaberem Object->Modify, izaberem tab 'Data' i ima ikona za modifikovanje transakcije.