On 02/05/11 21:37, Esteban Cervetto wrote: Hi!
>>> SCID don t ask me where the games are saved when I >>> init a game with Ctrl+x and I stay in the clipboard. >> >> They are saved in the clip base (not to be confused >> with the clip board). >> >> If you switch to a "regular" base, they are created >> there. > > I accidentally close SCID. Can i recover it? No. As for Steves suggestion: we could dump out the last game of the clipbase to some file, but I fear it would not solve your problem at hand. If we dump out the last game you edited you loose all those you worked on before as it just gets overwritten. If we always append if you hit save, we'd accumulate quite a bunch of duplicates there. If we dump out the whole clipbase this might actually be quite a bunch of games depending on your usage of the clipbase so it would at least be slow. It would then acutally be more suitable to create a temporary database instead and use this as clipboard. However, this would drop the huge performance gain you get for certain operations if you do it in memory, ie. the current clipbase mode. (Dumping to PGN doesn't seem the right format, IMHO, as it looses additional information like flags and so on you might have added and it might become quite big and inefficient as well.) >>> I saved my game, but when I close Scid, I lost the game, or I dont >>> know whre the game is located >> >> The clip base is not saved when you quit scid, indeed. > > Thats the problem! so, Why Can I need save a game in the > clip base? If you work on a game nothing gets stored to whatever database (memory or disk) unless you explicitly store the game (Game / Save or Save Replace). The important thing to learn here is that you never save "the database" but always work on a per game level _within_ a database. For an analogy you can think of a database as a folder on your file system and of a game as a file in that folder. Having understood that very important point it is clear why you want to "store" a game in the clipbase: otherwise all your changes would not go into that very game. Working in the clipbase e.g. would make sense if you want to add a given game to several databases in succession (though I'd work the other way round here as well). Or if you really just want to try out some things that should get lost. > In my point of view, It is easier and safer that, when the > user tries to save a game from the clipbase, Scid should > ask for the database to save it. Actually, you should think the other way round: if I want to work on a game and store it permanently, first decide which database it should go to, open that database and add the game there in the first place. Like in the anology above, first open the folder, then create the document. Probably, for your usecase, instead of opening Scid it would probably be better to just open the database by a double click in whatever filer you use? Then you're right in the database to work on and your games get stored into the correct place. This is what I usually call document centred. This also avoids this nasty "File/Open" stuff and navigation through a file tree with less suitable tools then a decent filer. But it's another workflow, probably one one has to get used to first. I admit, that given the fact that the clipbase in Scid is actually equipped with all functions of a database one might be lead to work the other way round. Especially, if one uses some program centred workflow instead of a document centred one. Still, the simple fact that the clipbase offers all functionalities like a real database gives you a very powerful tool for complex searches and selection, copy&paste functions and so on. So it doesn't seem wise to restrict this. As for the suggestion to ask the user "you have unsaved games in the clipboard": first I think it is not entirely trivial to do on a technical level though it could be done. But how should it work if you actually add 5 games that should go to different databases? Asking for all games in sequence isn't probably to wise as you might well have several hundreds of games in your clipbase in many other circumstances. Just as a random example I have every day: the CC functions of Scid work very heavily with the clipbase as temporal storage. So usually at the end of a session I tend to have about 20 or more "unsaved" games in the clipbase. However, they're all stored as they get synced into the CC games base. Or if I do some selections to study a given position I usually select games from several sources pack them up in the clipbase to export them to some PGN file for Droidfish. In all those cases asking about storing the clipbase would be a bit anoying. I admit that I don't like the handling of ChessBase here as reported by Gerd, ie. having only references to some real databases in the clipbase would introduce quite some issues that break a lot of functionality or drop some niceties the current approach has. cu Alexander ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
