11.05.2014 0:18, Vlad Khorsun wrote: > It is wrong for "lost update" scenario, which is allowed for > read-committed transactions: > > att1: start tx1, insert version1 (blob1), commit tx1 > > att1: start tx2 (read-committed), read version1 (blob1) > > att2: start tx4, update version2 (blob2), commit tx4 > > att1: update version3 (blob1), commit tx2 > > Here we have chain of versions: > > version3 (tx2, blob1) -> version2 (tx4, blob2) -> version1 (tx1, blob1)
I have tested it with following script: create table g_test (f integer, b blob sub_type text); insert into g_test values (1,'abc'); commit; select * from g_test; commit; set term ^; set transaction read committed^ execute block as declare variable b1 blob sub_type text; begin select b from g_test into :b1; in autonomous transaction do update g_test set b='qqq'; update g_test set b=:b1; end^ commit^ select * from g_test^ set term ;^ As the result, content of the blob was the same, but id was different. What did I wrong? -- WBR, SD. ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
