TIBSQLMonitor ONSql EventText trunca la sentencia sql
 

Hola.
Utilizo TIBSQLMonitor para guardar las sentencias de Insert, update, delete y commit que empleo en mi aplicacion

El problema es que el evento OnSQL utiliza una variable (EventText) de tipo String que es insuficiente para contener algunas de las sentencias que utilizo.

He oído que se puede arreglar el bug EN IBX.SQLMONITOR.PAS pero no sé cómo arreglarlo

¿Alguna idea?

Efectivamente es una limitación conocida del componente TIBSQLMonitor de IBX (InterBase Express), que usa un buffer interno limitado para el texto del evento OnSQL.
Te copio lo respondido por chatgpt:
�� Problema

La variable EventText que se pasa al evento OnSQL es de tipo string[255] en la unit IBX.SQLMonitor.pas, lo que limita el tamaño del SQL capturado a 255 caracteres.
Esto se puede solucionar modificando la unidad fuente IBX.SQLMonitor.pas.
✅ Solución: modificar IBX.SQLMonitor.pas

1. Localiza la unidad IBX.SQLMonitor.pas en tu instalación de Delphi.
   Suelen estar en la carpeta de los sources de IBX o Delphi, algo como:
   C:\Program Files (x86)\Borland\DelphiX\Source\IBX\
2. Abre la unidad y busca esta sección en el tipo TIBSQLMonitor:
   TIBSQLMonitor = class(TComponent) ... private ... procedure DoSQL(EventText: String); ... Y también el evento público:
   type TSQLMonitorEvent = procedure(EventText: String) of object;
3. �� Cambia el tipo del parámetro de String a AnsiString o WideString (según lo que uses):
   TSQLMonitorEvent = procedure(EventText: AnsiString) of object; Y cambia también la declaración de DoSQL:
   procedure DoSQL(EventText: AnsiString);
4. Asegúrate de que las variables internas que arman el texto de SQL también usen AnsiString si están limitadas.
5. Recompila el proyecto y recompila cualquier paquete que use esta unidad si es necesario.

⚠️ Notas importantes

• Si estás usando Delphi 6, como me comentaste hace poco, es posible que debas adaptar un poco según el tipo de String que estés usando. En Delphi 6, String es de hecho un AnsiString, pero si en alguna parte se define como ShortString o string[255], ahí está el problema.
• Si usas Packages, asegúrate de recompilar IBX y cualquier paquete que lo use.
• Alternativamente, podrías copiar IBX.SQLMonitor.pas a tu proyecto, modificarlo ahí, y asegurar que tu proyecto use tu versión modificada, no la compilada por defecto en la BPL o DCU original.

Gracias, lo he intentado pero me da error al compilar o simplemente no obtengo nada en la variable Eventtext.

Lo mismo te interesa debugview que captura lo que envías a outputdebugstring.


Vuelvo a copiar la respuesta del chatgpt, yo he usado esas opciones en distintos proyectos. (Por eso te lo copio, tendría que estar proyecto a proyecto buscando, copiando, etc. así que aquí va un resumen).


Con Firebird puedes registrar lo que se ejecuta desde un programa Delphi (u otro cliente) de varias maneras. Aquí te explico las opciones disponibles para auditar sentencias como SELECT, INSERT, UPDATE y DELETE, especialmente si quieres guardar esa información en una tabla propia.
🔐 1. Triggers para INSERT, UPDATE, DELETE

Firebird permite crear triggers en cada tabla para registrar lo que ocurre.
Ejemplo:

CREATE TABLE tbauditoria ( id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, fecha TIMESTAMP DEFAULT CURRENT_TIMESTAMP, tabla VARCHAR(50), operacion VARCHAR(10), usuario VARCHAR(50), datos TEXT ); En cada tabla que quieras auditar:
CREATE TRIGGER tr_aud_ins BEFORE INSERT ON clientes AS BEGIN INSERT INTO tbauditoria(tabla, operacion, usuario, datos) VALUES ('clientes', 'INSERT', CURRENT_USER, 'nombre=' || NEW.nombre); END Lo mismo puedes hacer para UPDATE y DELETE.
✅ Ventajas:

• Rápido de implementar
• Guarda la información dentro de la misma BD

❌ Limitaciones:

• No captura los SELECT
• Puede impactar el rendimiento si no se gestiona bien

🔍 2. Firebird Trace API (desde 2.5+)

La Trace API permite capturar TODAS las operaciones ejecutadas (incluso SELECT), sin modificar el código ni las tablas.
Puedes crear un perfil de trace y usarlo así:
fbtracemgr -se localhost:service_mgr -user SYSDBA -password masterkey -start -name mi_trace -config trace.cfg Archivo trace.cfg de ejemplo:
database=<path o nombre de tu base de datos> { enabled = true log_connections = true log_statement_start = true log_statement_finish = true log_errors = true time_threshold = 0 include_filter = "" } ✅ Ventajas:

• Captura todo: SELECT, EXECUTE PROCEDURE, INSERT, etc.
• No requiere cambiar el esquema de la BD
• Puedes guardarlo en archivo o procesarlo desde una app

❌ Limitaciones:

• No guarda en tabla directamente (tienes que parsear el log si lo deseas)
• Solo disponible en Firebird 2.5+

🧩 3. Firebird External Engine / Middleware

Otra opción más compleja es usar:

• Middleware (como un proxy) entre Delphi y Firebird
• Procedimientos almacenados que usen EXECUTE STATEMENT y a la vez logueen

Esto es más raro y complejo, pero viable si usas acceso centralizado a la BD.
💡 Consejo si usas Delphi

Si accedes a Firebird a través de una capa común en Delphi (por ejemplo una clase o función que centraliza las consultas), puedes añadir logging desde Delphi mismo, y guardar en una tabla tipo tbauditoria.
procedure EjecutarSQL(const SQL: string); begin GuardarAuditoria(SQL); // Guarda en tabla con usuario, fecha, etc. IBQuery.SQL.Text := SQL; IBQuery.ExecSQL; end; 🧠 En resumen:

Opción ¿Captura SELECT? ¿Guarda en tabla? Complejidad Triggers ❌ No ✅ Sí Baja Trace API ✅ Sí ❌ No (pero se puede procesar) Media Logging en Delphi ✅ Sí ✅ Sí Baja (si tienes control del código) Middleware/Proxy ✅ Sí ✅ Sí Alta

De todas formas, ve diciéndonos exactamente lo que haces, el código que usas, el resultado, etc. y te vayas ayudando paso a paso.