[Firebird 3.0] [Trace] fbtracemgr.exe doesn't trace changes

[wryczko]

Steps to reproduce:

Given:

Firebird 3.0 database setup:

• install Firebird Server 3.0.10 (x64) on Windows 10 with default configuration https://firebirdsql.org/en/firebird-3-0-10/
• create an empty database https://firebirdsql.org/manual/bk02ar08s06.html
• add some test table to a newly created database
• start tracing for database changes by runningfbtracemgr.exe -se service_mgr -user SYSDBA -pass masterkey -start -conf C:\temp\fbtrace30.conf in console (cmd) from within Firebird 3.0 catalog - like described in https://ib-aid.com/en/articles/how-to-run-firebird-tracing-for-visualization.

When

• insert new row into a table using any means (e.g. DBeaver GUI)

Then

Expected behaviour:

• Console (cmd) shows info about a SQL Insert statement being executed on database

Current behaviour:

• Console (cmd) shows only Trace session ID 1 started

Additional info

• Described scenario works on Firebird 2.5
• I managed to have it work on Firebird 3.0, but I had to add one of the prefixes to service name e.g. inet://service_mgr, localhost:service_mgr, 127.0.0.1:service_mgr
• Related issue https://github.com/FirebirdSQL/NETProvider/issues/1098

[hvlad]

When you run tracemgr not using remote protocol prefix, it runs in embedded mode (since Firebird 3). Also, note, it runs by interactive user account and in corresponding user Windows Session. Firebird server runs as service, I assume, thus it runs in system Windows Session (Session 0). Shared memory used by trace services uses different memory mappings in different Windows Sessions. Therefore trace manager from embedded process can't see events generated by attachments in Firebird service process, and vice versa. Simple workaround is to use remote protocol when attaching to the services manager when you need to trace attacments served by Firebird running as a service.

'local' connections works in Firebird 2.5 at it was not embedded, but uses XNET implicitly

It should be fixed by #7213

[wryczko]

Thank you @hvlad for a quick response! That makes sense. Do you think this might be the reason why FirebirdSql.Data.FirebirdClient has an issue with tracing? I explained it in more detail on another ticket https://github.com/FirebirdSQL/NETProvider/issues/1098

[hvlad]

Do you think this might be the reason why .NETProvider has an issue with tracing? I explained it in more detail on another ticket FirebirdSQL/NETProvider#1098

I'm not too familiar with .NETProvider, sorry. Try to run Firebird as application, not as a service and, if your application will be able to see traced events, then it is the same reason, else problem is elsewhere and needs additional investigation.