The Log window uses the logging service to provide a record of activities during a Manifold session.
Open the Log window with View - Panes - Log Window menu command.
Each log entry provides the date, time and the event which is prefixed with an event type indicator using the following characters:
|Messages from scripts
Messages from highly transient activities such as rendering times are marked with a blank type indicator. For example, in the illustration above the five lines indicating rendering times for a map have a blank type indicator while the preceding five messages are preceded by the double-dash -- indicator for regular messages. The screen shot shows times to open a project and then to open and to display a map window with three layers, which show all lakes, water areas and watercourse lines in Australia.
Log messages from dataports include the full path to the relevant data source. Log messages from windows include the full path to the relevant component or data source. Running a query from the Project pane logs the execution time and running a script from the Project pane or from a script window logs the execution time as well.
The Log window will report rendering times for map windows.
The Log window can be docked or undocked like other windows with a Shift-Click and it can be moved to the second row of docked window tab with a Ctrl-Click like other windows.
for more verbose information in the Log window when launching a query from the Command Window, run the !fullfetch directive. The !fullfetch directive toggles more verbose information reporting on/off in the Log to include the time required, number of records involved and size of data involved. To run this directive, enter !fullfetch in the Command Window, highlight the !fullfetch text and press Alt-Enter to run just the highlighted text. !fullfetch works both with Manifold queries as well as queries executed within an external query engine.
Caution: Enabling !fullfetch can reduce performance. Do not use !fullfetch with large jobs.
!fullfetch provides means to get a better idea of how long it takes a query to run. In theory, measuring the time required for a query is simple: the query engine runs the text of the query and we measure how long that takes. In practise, the situation is not so simple.
For example, with some statements the query engine can postpone some or most of the actual computations and return the result sooner than all postponed computations are done. In particular, when the query is a SELECT, the result of running that query is a table, and the query engine can immediately return the table, but it might be only when records are actually fetched from that table that some postponed computations will be done.
That is a good thing, because we get the result table faster, and we can start working with the first records in the result without the system computing further records. We might look at the first records returned and decide we have what we need with no need to compute further records. There are many scenarios postponing computations not immediately required avoids doing unnecessary work. But such optimizations do mean that we cannot measure the performance of the query simply by measuring how long it takes the query engine to return a result.
This is where !fullfetch comes in: the directive tells the Command Window that is operating the query engine to not just run each next command but also to take the result table and read through all of it, thus forcing the query engine to compute each record. The result table produced is exactly the same as without !fullfetch, but when we use !fullfetch the but the Command Window reads through the entire result table once after the query engine returns it, and the time to read through the result table is included in the time measurement reported in the Log Window.
Using !fullfetch makes no difference with INSERT, DELETE, UPDATE and similar because the result table of such commands is a small table with a single row in it, that reports the number of affected records. No time is required to read a single row. In contrast, using !fullfetch can require more time in the case of SELECT that return many rows, and possibly EXECUTE as well, depending what happens inside the EXECUTE.
A simple way to get a rough equivalent to times reported using !fullfetch, but without using it, would be to do a SELECT INTO instead of SELECT. A SELECT INTO without !fullfetch would take slightly longer than SELECT with !fullfetch, because SELECT INTO not only has to read through all data, it also has to take additional time to write all data into a new table, but the effect would be similar to using !fullfetch.
The logging service automatically saves a log containing all log entries for which the event type indicator is not blank to a file using UTF8 text file format. Highly transient activities such as rendering times which are marked with a blank type indicator are not saved to the log file.
By default, log files are written to the Windows folder for user application data, C:\Users\User\AppData\Local\Manifold\v9.0, (where User is the login name of the user who launched Manifold) but if desired we can change that location to one of the Manifold system folders such as the extras folder if our user login has write privileges to that folder.
To do so, we create a blank manifold.loghere file in the desired folder. For example, within the extras folder we can create a logfiles folder and within the logfiles folder we create a blank manifold.loghere file. Thereafter logging files will be created in the ~\extras\logfiles folder.
As a practical matter most users will not have write permissions to Manifold system folders so they will leave their logfiles in the default path of C:\Users..., but in the case where we are using a portable installation and have full control with write permission to the Manifold system folders we can change the path for logfiles to a system folder.
Manifold starts a new log file every day. A working session of Manifold will use the log file for the day it was launched. If the log file for the current date is locked by a different Manifold session, the system will create a different log file for the same date with a unique postfix.
If Manifold is used from another application all logging is turned off.
The log also records the results of loading system libraries and non-system libraries on startup. Successful loads of system libraries report nothing, successful loads of non-system libraries report the full path of the loaded module (useful when there are multiple modules with the same name) and failed loads report errors both for failed loads of system libraries as well as failed loads of non-system libraries.
The origin of imported components - We can get the path to a file that was imported by looking at the Log Window, which logs the path used for import operations.
2021-06-29 12:01:32 -- Import: C:\data\OSM Venice\shapefiles\wiki landmarks.shp (0.007 sec)
That can be convenient, since text can be copied from the Log Window, and then pasted into any comments components giving the origin of a particular layer.
The origin of linked data sources - We can also get the path to a file that is linked by looking at the Log Window, which logs the path used for link operations.
2021-06-29 14:39:13 -- Link: C:\data\OSM Venice\ESRI Venice.map