In an opening tree (also called "opening explorer" or "openings book") on ChessBase 12, here are the statistics that we get after 1. Nf3 c5 :

So it seems that after 1. Nf3 c5 White will play 2. e4 93% of the time.
It is obvious that these statistics are nonsense.
Everyone knows that after 1. Nf3 c5 White will play 2. c4 50% of the time, 2. g3 30% of the time, and 2. e4 only 10% of the time.
White players who play 1. Nf3 are generally not very interested to get into an Open Sicilian...
"2. e4 464238" does not mean "in this position White has played the move 2. e4 464238 times", it just means "the position reached after the move 2. e4 has been reached 464238 times by different move orders".
How can we resolve this problem?
It should not be physically impossible, since most other opening trees do not have this issue (ChessOK's opening tree, 365Chess' opening explorer and FICS' opening explorer do not have this problem).

When we do a right click, and then click on "Properties", this window pops up:

But unfortunately checking or unchecking the box "Unplayed transpositions" does not seem to do anything.

  • 1
    Unchecking "Unplayed transpostions" will only prevent the Openings Book tab from displaying moves that were never made in its database but still lead to a position in its database via transposition. – dfan Jan 2 '15 at 15:34
  • Chess.com also does this, Scid does it the way you feel is correct. – RemcoGerlich Mar 5 '15 at 9:39

Unfortunately, many of the statistical functions of the Opening Book feature in ChessBase have been unreliable in every version I've owned.

For example, after the Caro-Kann line 1. e4 c6 2. d4 d5 3. e5 Bf5 4. Nf3 e6 5. Be2 Nd7 6. O-O h6 7. Nbd2 Ne7 8. Nb3 Qc7 9. Bd2, the opening book PowerBook 2013 shows this table:

Move       N     %    Av  Perf
          15  76.7  2409  2283

9...Bh7    8  56.3  2433  2494
9...g5     6  83.3  2405  2233
9...Nc8    4  62.5  2393  2335
9...a5     2  50.0  2561  2564
9...Be4    1 100.0  2414  2315

Well, first off, you'll notice that the number of games in the total (15) has no relation to the number of games in each variation given (a total of 21).

Second, if you do some simple arithmetic, you can work out that the average White win percentage is actually 66.7%, not 76.7%, as reported.

Well, then, let's ignore the overall position total statistics, and move on to examining a line item. Let's look at the 9...Bh7 line, which this table says was derived from 8 games, with a White winning percentage of 56.3%

If you make that move, you get a new table. Since we're now at the new position, the position statistics at the top of the new table should read the same as those from the 9...Bh7 detail line of the parent table from the prior position, right?

Here's what they actually say:

Move       N     %    Av  Perf
           8  56.3  2545  2484

Not bad, right? The first two stats agree... but the Average ELO and Performance ELO numbers are off by 100 ELO in the 1st stat, and 10 ELO in the 2nd.

And here's the full table for the new position

Move       N     %    Av  Perf
           8  56.3  2545  2484

10.a4      4  75.0  2455  2513
10.Bb4     4  62.5  2557  2537
10.Rc1     2  50.0  2650  2591

Again, the total # of games is unrelated to the # of games in each of the continuations. And this time, the White winning percentage works out to 65%, not 56.3%. And the position's Performance ELO is clearly not the average of the continuations' Performance ELO. It should be 2538, an error of 50 ELO.

I picked a ready example from a game I was looking at a few minutes ago, but any game will do to demonstrate this problem. I frequently find that when I try to choose a move from an apparently winning continuation that the the detail data from the resulting position just doesn't support the apparently "winning" statistic. In some cases, it could say White has as much as a 60% winning percentage for the continuation, and then in the next position none of the further continuations has a percentage higher than 50%. Simply put, it's nonsensical.

Now, here's where it gets interesting: I have set my Reference Database as the database of games that was supplied with PowerBook 2013 (PowerGames 2013). PowerBook 2013 was generated by ChessBase using all of the games from PowerGames 2013, and only those games.

I can now open the Reference window pane, and it will look up the statistics from the games in that database. They should be identical to the stats shown in the Opening Book pane, but they're not.

In fact, the Reference statistics for the 2nd position (after 9...Bh7) show the following:

10.Bb4     4  62.5  
10.a4      2  50.0  
10.Rc1     2  50.0 

This is where the total statistics in PowerBook 2013 are coming from! The total number of games = 8 (correct), and the average performance = 56.25% (correct)!

In fact, in the PowerBook 2013 continuation stats there appear to be 2 extra games where 10.a4 was played (and which White apparently won), but they don't appear in the Reference database stats at all, and they aren't factored into the PowerBook 2013 totals stats.

It doesn't really matter whether this is a problem inherent in the commercially-sold books from ChessBase, or in how the ChessBase database software uses/calculates/displays the statistics. Simply put, there's a defect here that's been present since at least ChessBase 6.0, and hasn't been fixed at late as Version 11 (the one I'm using). Just watch out for it when you try to use an opening book to pick a line based on its purported winning percentage. The best approach is to use the Reference Pane, or at least double-check the continuations for a couple of further moves.

Personally, I now use the Reference window pane for this purpose, and put up with the slight lag required to update the stats for every new position in the game. I use an AMD Quad processor at 2.9 GHz, so if you have something less powerful, you might feel the pinch a little more.

I'm not excessively critical of the ChessBase software in general; I use many of the features quite effectively. But a few of them have known faults you should know how to work around.

Another example: Try using a position search in a database; ignore the results. Then, edit the position within the search filter (add, move, delete pieces, whatever), make a note of the new position you're now searching for, and run the search again. Save the resulting list of games. Now, reset the search filter completely (I suggest closing and reopening the database as well). Finally, set up the (altered) search position again from scratch, and run the search a 3rd time. The results from the 2nd (edited position) and 3rd (fresh position) searches should match. They frequently do not. I've noted many cases where the fresh search filter returned many more games than the edited search filter. I have no explanation for this, but I no longer edit the position in the search filter. I always create a fresh position (usually by copying and pasting from a game window I set up for the purpose).

Hope this is helpful!

  • 1
    The Opening Book deals with positions, not variations, which can be confusing in the case of transpositions. In your Caro-Kann example, the position after 9.Bd2 occurred 15 times, out of which White scored 11.5/15 = 76.7%. The position after 9.Bd2 Bh7 occurred 8 times, but not all of these came from the position after 9.Bd2; some were transpositions. 21 games in total reached one of the five positions that occur when Black responds to 9.Bd2. – dfan Nov 5 '16 at 1:57
  • @danf Your explanation makes sense, but there isn't much point to knowing what the stats are for the position after 9 Bd7 if all of the moves from that position lead to a completely different set of statistics. In effect, it's a case of reverse-you-can't-get-there-from-here, in which you can't avoid going places that you didn't intend. I think it would be more intuitive and helpful to show the averages of the ELO and Win Rate for the continuations, instead of the stats for the position from which the continuations ensue, which are superseded by those of the transpositions anyway. – jaxter Nov 5 '16 at 5:39

You can get this information from the Reference tab, rather than the Openings Book tab. (Of course the stats will correspond exactly only if your openings book was made from your reference database.)


We do not know the exact format for Chessbase books, and it is entirely possible that what I'm about to say is not true in this case.

The open standard book formats that I know of (Crafty, Pro Deo, Polyglot) represent chess positions as a 64-bit Zobrist hash. You can google how one of these works if you want to, it's beyond the scope of this answer. This is likely the same for Chessbase books.

These hashes are designed so that the key for 1. e4 c5 2. Nf3 is identical to the key for 1.Nf3 c5 2. e4. This is useful for covering transpositions like this one. However, it means that it cannot distinguish between lines, resulting in there being no way of removing these transpositions.

TL;DR I suspect this is impossible because of technical restrictions in the Chessbase book format.


You can also create an opening key for the games, and arrange it the way you like. If you highlight a node in the key, and press 'S', you can see the statistics.

  • unfortunately, we're researching lines where each move has branches. Creating such a key would have to be automatic. The Reference function already does this on the fly; the difference is that the key is static/permanent, but the Reference report is dynamic/temporary. So, you can use the nodes of the key more than once, and pay the setup cost once. Using any position more than once in Reference requires repeating all the calculations each time. I don't know of an automated way to create such keys, but the Opening Book feature does the equivalent. But its stats are wrong... – jaxter Sep 26 '16 at 16:20

One solution that I have developed for this issue is that you can go to the first node. Now you take the game list and separate it. Then you use a tree on this to go to the second node. Etc. In the end you will end up with a list of games with the exact move order you are interested in.

I know it is cumbersome and that an automatic solution would be great, (like a switch you could flip in the tree to have it either way) but just thought I would throw this out there as a possibility if it's only a few lines you need exact move orders for.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.