In an opening tree on ChessBase, how can we fix the statistics so that transpositions are not taken into account in the total number of games? 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.
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!