Hello, as the developer of Scidb I like to answer to some points.
> The developer of scidb came to the same conclusion but starting from > scratch is also no good idea. Initially I started to re-design Scid (in fact I've implemented the SVG graphic firstly in Scid), but I gave up after some weeks. My conclusion was that starting from the scratch is the only possible choice, Scid's code is in a bad state. It's not really from the scratch, because Scidb is based on a deep analysis of Scid's code. > ...I am not interested in. No alternative for Chessbase, n > functionality to manage large databases ... Yes, ChessBase is designed for huge database, and Scid/Scidb is definitively not designed for huge database. More than 1.5 million games in a database is not recommended for Scid/Scidb. ChessBase is ChessBase, and Scidb will not be ChessBase, Scidb will be Scidb (not a fork of Scid as well!). Scid/Scidb provides some functionality which ChessBase cannot provide, for example the very fast position search (ChessBase is working with memory mapping, no chance; furthermore ChessBase has to decrypt his game data!). The user has to decide what he wants, and if Gerd likes to work with huge database then ChessBase is the primary choice. But if the user is only working with specialized databases (only the opening repertoire he is usually playing, for example) he may prefer the features of Scid/Scidb. Gregor ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
