What's New in V2.0?
This section is for people who are already familiar with FB TraceManager 1 and are looking for a quick overview on what's new in V2.0.0. A detailed change log is available in the History section. In short, V2 makes the Firebird trace experience even better. But before discussing the new features, a quick note on compatibility to V1.
Compatibility to V1
Per default, V2 gets installed into it's own directory. Check out the Installation section. You can re-use an existing V1 FBTM.fdb database by following these steps:
|•||Close all running FB TraceManager processes including FBTMLoggerSvc3 services (if any).|
|•||Go to the FBTM.fdb database directory. Usually this is C:\Users\<account>\AppData\Roaming\FB TraceManager.|
|•||Make sure (e.g. by renaming the database file) that nobody is actively using the database and copy it over to the new user-specific application directory. See the Installation section.|
|•||Rename the pre-installed FBTM3.fdb database to something else and rename your existing V1 database to FBTM3.fdb.|
|•||Run FB TraceManager 3. It will take care of upgrading the database to the newest version.|
Now it's time to discuss the new features. Keep on reading.
The multi-threading support has been completely rewritten. In V1, the graphical user interface has been notified immediately after receiving a trace line and/or a parsed trace event, which blocked the background trace data receiving thread until the graphical user interface has been refreshed. The multi-threading model in V2 has been changed in a way to puffer received events in a thread-safe queue and post-pone processing with a user-definable GUI refresh interval. This makes the user interface in general more responsive with busy active trace sessions and decreases CPU utilization. The refresh interval is a per-project setting and can also be changed for a currently active trace session. Another benefit from the new threading model is that in case of a suspended raw/parsed visualization, received events are queued and processed when the visualization is resumed or completely dismissed from the queue without visualization when using the Dismiss When Paused option.
Improved Raw Output
The raw output experience has improved a lot:
|2.||The background color of a raw line which marks a new trace event can be set with a custom color|
|3.||Syntax highlighting is enabled for SQL in general and for trace event types (PREPARE_STATEMENT, CLOSE_CURSOR etc.)|
|4.||You now can collapse/expand (folding) the raw output of entire trace event blocks|
|5.||Define custom bookmarks in the raw output via CTRL + SHIFT + [1..9] and locate them with CTRL + [1..9]|
|6.||It's also easy to navigate to the parsed trace event for the raw trace event at the current cursor position by using the context menu|
The following screen shows the new raw output in action.
Right-clicking in the raw output pops up a context menu with a Go To Parsed Event menu item to navigate to the parsed trace event for the current cursor position.
These enhancements are also included the freely available Lite Edition!
Improved Parsed Output
The parsed output has been improved as well:
|1.||A footer band allows you to execute an aggregate function (avg, count, count distinct, max, min, sum) per numeric column independently. The aggregate function can be chosen with a context menu on the column in the footer.|
|2.||Filtered columns are marked with a special icon in the column header.|
|3.||Double-click in the grid or use the context menu to locate the selected trace event in the raw output.|
|4.||You can copy a column value via the context menu to the clipboard by using the Copy menu item. You will see context-based submenu items with column names, where the column value is not empty.|
|5.||You can set a column value as a regex filter via the context menu by using the Set Filter menu item. You will see context-based submenu items with column names, where the column value is not empty.|
|6.||You can set the footer band column value as regex filter as well.|
The following screen shows the new footer band and the filtered icon in the column header.
Beside the parsed output enhancements, the EXECUTE_BLR trace event is now fully supported as well.
Improved Event Processing
Event Processing is a very useful feature to detect certain conditions in parsed trace data. The event processing engine has been enhanced with two new rule types:
|1.||OnExecuteApplication: The event rule code is executed for each cell of a parsed trace data row and allows to execute an application by it's file name with optional parameters.|
|2.||OnPlaySound: The event rule code is executed for each cell of a parsed trace data row and allows to play a .WAV file or a Windows system sound.|
Improved Windows service implementation
The Windows service application FBTMLoggerSvc has been optimized in respect to memory usage, which makes it capable to run 24x7 without running into out of memory scenarios.
Beside the Windows service application being able to run 24x7, FB TraceManager has been extended with an configurable automatic purge strategy, which enables running FB TraceManager in 24x7 scenarios even with an activated Trace Data Visualization.
There have been various usability enhancements added in this new major release:
|1.||Dockable/pinnable "flyout" tool panels were added at various places, e.g. the Management Console in the main window, Report Management in the Reports module and Analysis Management in the Analysis module. The various areas (Rule Management, Object Browser, Code Catalog) in the Event Processing module are using these tool panels as well, saving space for typing event rule source code.|
|2.||Regex filters can be applied on the list of projects and server-side trace sessions.|
|4.||A Minimize to tray option in the Settings allows to move the program icon to the Windows notification area upon minimizing.|
|5.||An Auto connect option in the Register Server dialog allows to automatically connect to the server when starting the program.|
|6.||Similar to duplicating a project, report etc., a server entry can be duplicated as well.|
Beside new features, various bugs have been fixed to improve the stability of the product. Especially the re-written multi-threading part has cleared out some race conditions when running several busy trace sessions simultaneously. Beside stability, an annoying, well-known bug has been fixed, which was the reason that the parsed output was always one event behind the raw output. This also applies to the Windows service application FBTMLoggerSvc. The new threading model made this easy.
For a full list of fixed bugs in the V2 cycle, check out the History.