Understanding how a program execution proceeds often helps debug the program. An execution can be seen as a succession of computation steps. Tracers give information about these steps and what occurs at each of them. The traceable steps are traditionally called breakpoints. An execution frequently produces several millions of breakpoint occurrences. Programmers can therefore not analyze by hand all the computation steps. Existing tracers often have conditional breakpoints to inspect only steps which satisfy certain conditions. Unfortunately, the conditions that can be specified do not meet all the needs. To palliate this problem, an execution trace can be seen as a relational database. Each breakpoint information is represented by a tuple and queries simply use the language of the database management system. The problem is then that the time to create the database is much too long. We have, therefore, proposed an improved framework for trace querying. The interrogation is processed in two distinct steps: firstly, the trace is filtered on the fly with respect to the basic conditions of the queries; secondly, the remaining part of the query is then processed. Our approach has two main advantages. Firstly, filtering is very efficient. Done on the fly, it creates very few new data structures, the trace does not even have to be stored at all. In this report, we describe how to implement trace query tools based on the above framework. We propose an architecture where a tracer driver, containing a very efficient trace filtering algorithm, is integrated in the tracer process. The implementation guidelines are based on our experience building four prototypes for different sorts of programming languages.