Pascal Georges schrieb: Good Morning!
Unfortunately I had to prepare a talk yestereve that took a bit longer so no news from the front yet. >> I know your point, and I'm really trying hard to give more >> information to nail it down. Now I'll go home for today and >> maybe work in another bunch of refs. Maybe I can come up >> with some addtional information. > > I made a code review, and maybe I have the start of an > explanation. When you replace a game, the block is flagged > as "dirty" (gfile object). Sometimes this block is flushed > to disk (at least when the base is closed). As the name of > a player is changed, Scid has to update it in game data > (sg3 file) and there are also some info in index entry > (si3 file) and in the name file (sn3 file), and I don't > really got when all those are synchronized. Ic! Now: the search is done with or without reading data from the disk? I.e. does scid read in all indicees from sg3 and si3 into memory or does it recall some of it from the actual files where a block may not yet have been written? > So next time you encounter this, don't close Scid but > simply issue a "close + open" base. I looked at search > function and I saw nowhere any flush of data, so maybe > sometimes when you are looking for data with dirty blocks > that you updated, things don't work well. That could explain a a bit. The contents of the last books I entered did sometimes conatain games from the same tournament, but that was not the rule. I.e. I did not enter a tournament book. Now, Nimzowitsch was pretty fond of his own games so he was one who refered permanently to his own wins and there were indeed quite some games spread accross the chapters that stem from the same tournament. Not in a row, but one on p.50, the next on 76 and yet another on 152 or something the like. Hence, the scenario you describe might well happen there and it is actually most likely to happen in Nimzowitschs book. > But this bug should also exist in Scid 3.6.1 ... so if you > manage to reproduce it, it would be interesting to try it > under Scid 3.6.1. Ack. There is a way I can check wether it existed in previous versions and just may gone by unnoticed: my DB is not complete, ie. some games from the books are missing, or I did not find them when I inserted the books metadata. And I marked those in my books. Therefore I could recheck those marked wether I can find them now. If this happens I could confirm that the bug exists in 3.6.1. If not I could not rule it out but just say that I never saw it till now of course. Additionally there is a good reason for this recheck, therefore I wanted to do it anyway. > But even if it can't be reproduced with Scid 3.6.1 does > not mean the bug is not explained : due to block size > changes, games are not in the same block numbers if you > change Scid version, so the bug may or may not pop up, or > more precisely it can pop up at various stages. Now I understand much better what might happen here. Thanks for the explanations! > I must confess I should never have changed block sizes. I admit that a change in the DB format should have stated somewhere in friendly, big, red letters ;) Anyway it seems that the DB itself was never corrupted! At least what looked corrupted in the first hand always was ok again after restarting scid and reopening the DB. That is, just the search results where not complete. This is an inconvenience of course, but it could have been worse. > Years ago I had corrupted bases with Scid (that were easy > to fix), but did not get any for a long time .. So for me > I think things are quite hardened and robust now. That was my experience with scid till now. Actually I never had problems with a corrupt database, that's why I invested quite a bit of work into this special ref db. -- Kind regards, Alexander Wagner Universitaetsbibliothek Ilmenau Langewiesener Str. 37 98693 Ilmenau Tel.: 03677/69-4521 , Fax.: 03677/69-4617 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
