This build is designated as a development build because we made a change in the optimizer that could affect a lot of applications. We don't expect it to cause any problems (it fixes one possible error case), and you are free to Go Live with it with your products. We just ask that you test your code and let us know if there are any problems.
Logging Build
This build is a full logging build. Logging does not happen automatically against every run of the engine. You have to turn it on from the Diagnostics namespace, and the Customer Experience tray app has to be running with logging enabled. By default the only thing we are logging in the CEIP application are Data Builder runs, and the Visual Studio tools (logging exceptions, errors, etc).
To turn on diagnostic logging within your application
At app or unit test startup you would call the startup like this:
VistaDB.Diagnostic.Support.BeginLogging("Starting Test to demo some error");
Then during your application shutdown call the EndLogging method:
VistaDB.Diagnostic.Support.EndLogging("Test shutdown complete");
You could also do the begin and end just around a problem area as well.
There are two boolean options on the logging right now to turn on additional information. By default we only log exceptions and errors in the engine process. If you are having a problem with an output being incorrect, or some other SQL specific problem you can turn these two options on to log more detailed information.
VistaDB.Diagnostic.Support.IncludeCommandSQL = true;
VistaDB.Diagnostic.Support.IncludeDataReaderRows = true;
The IncludeCommandSQL includes each SQL command that is executed and the parameters passed as a part of the query.
The IncludeDataRows will log each row returned to the command (NOT recommended unless REALLY necessary to see a problem since these rows can get quite large).
Issues and Fixes
Changed the optimizer code to be a little more deliberate in its choice of indexes. There was an error case where a compound index containing two columns also had a duplicate index covering the first column of the compound index.
Index1 = COLA, COLB
Index2 = COLA
The optimizer could pick either of them to satisfy a where clause against COLA. In fact it would pick the first one it found and use it in most cases. But this lead to an error when COLB was not used at all in the query (without constraints). You could end up with entries in the index that don't strictly match your constraint.
The fix was to actually choose the exact match when available. If we find an index that has an exact match on your query constraints we will use it over all others. The edge cases come when a query has one and not the other column, or when you have multiple covering indexes AND a compound index. We have tested as well as we can the various combinations, but there could always be an edge case we missed. There are actually 4096 combinations of index, order and column type. Makes it pretty hard to test them all, but the code is generic and doesn't actually care about the types or order.
Fixed an issue with order by that prevented the system from recognizing columns in aliased tables.
Example using DBDEMOS.vdb4 sample database:
SELECT o.[OrderNo]
FROM orders o
ORDER BY o.[OrderNo] ASC
This would fail due to the alias column and has been fixed.
Fixed issue created by change to the |DataDirectory| handler, also added unit tests to prevent regression.
Subscribe