Consulta SQL Asistida 2.0: de AG Grid a una web estática en el WebBrowser de PowerBuilder


 Hace unos meses os contaba cómo había integrado AG Grid con React dentro de PowerBuilder (si no lo leísteis, aquí está: https://rsrsystem.blogspot.com/2026/03/ag-grid-react-en-powerbuilder.html).

Mi Consulta SQL Asistida utilizaba ese grid y la verdad es que funcionaba muy bien. Pero con el tiempo me di cuenta de una cosa: para un visor de consultas SQL aquello era matar moscas a cañonazos.

AG Grid es una auténtica bestia, pero mi necesidad no era construir una aplicación de análisis de datos avanzada. Necesitaba algo más sencillo: escribir un SELECT, ejecutarlo y visualizar el resultado dentro de PowerBuilder.

Así que decidí darle una vuelta y simplificar.


Por qué el cambio

AG Grid ofrece prácticamente todo lo que puedas imaginar: agrupaciones, pivotes, exportaciones, temas, componentes avanzados...

El problema no era AG Grid, que sigue siendo una librería fantástica. El problema era todo el ecosistema que venía detrás para una ventana relativamente sencilla: React, Vite, npm, procesos de build cada vez que modificaba algo y una carpeta dist que desplegar.

Para una herramienta cuyo objetivo es "escribe una consulta y enséñame el resultado", el coste de mantenimiento no compensaba.

La nueva versión es una web estática:

  • un index.html
  • un app.js
  • un style.css

Sin frameworks, sin npm y sin procesos de compilación.

¿Quiero cambiar algo? Edito el fichero, cierro y vuelvo a abrir la ventana.

Las únicas librerías externas son CodeMirror 5 para el editor SQL y Tabulator para la rejilla. Ambas están almacenadas localmente, sin CDN y sin depender de conexión a Internet.


Qué sabe hacer

El editor utiliza CodeMirror con resaltado SQL estilo SSMS.

Dispone de:

  • ejecución con F5 o Ctrl+Enter
  • zoom de letra mediante Ctrl + rueda del ratón
  • navegación cómoda por el código
  • coloreado de sintaxis SQL

A la izquierda están los paneles de Tablas y Campos.

Seleccionas una tabla, marcas las columnas que quieres y el SELECT se genera automáticamente. Además, no lo hace colocando una columna por línea, sino adaptándose al ancho disponible del editor, como normalmente escribiríamos una consulta a mano.

También tiene navegación mediante type-ahead: escribes una letra y salta directamente a la primera tabla que empieza por esa letra.


La Grid de datos

La visualización de resultados utiliza Tabulator con un aspecto inspirado en SQL Server Management Studio.

Incluye:

  • ordenación por columnas
  • mover y redimensionar columnas
  • filtros individuales por columna
  • menú de operadores de filtrado
  • menús contextuales para copiar una celda, filas completas o todo el resultado con cabeceras
  • exportación a Excel real (.xlsx)

Los divisores entre paneles se pueden mover mostrando una línea guía para indicar dónde quedará el corte.

Además:

  • recuerda la última consulta ejecutada
  • conserva la distribución de columnas
  • utiliza mensajes tipo toast en lugar del clásico MessageBox

Pequeños detalles que hacen que la herramienta parezca una aplicación integrada y no simplemente una página web incrustada.


Edición controlada: INSERT, UPDATE y DELETE

Aquí viene una de las partes más interesantes.

Si el SELECT cumple unas condiciones:

  • consulta sobre una única tabla
  • devuelve todas sus columnas
  • la tabla tiene clave primaria

la rejilla pasa automáticamente a modo editable.

Puedes:

  • modificar valores con doble clic
  • insertar nuevas filas
  • eliminar registros seleccionados
  • guardar cambios

Internamente la ventana genera los comandos:

  • INSERT
  • UPDATE
  • DELETE

utilizando parámetros y aplicando el WHERE mediante la clave primaria.

Nada de concatenar SQL directamente con valores introducidos por el usuario.


El framework API: cualquier SELECT, sin conexión local

Y aquí está una de las diferencias importantes respecto a una ventana SQL tradicional.

La aplicación PowerBuilder no tiene conexión directa a la base de datos.

Toda la comunicación se realiza mediante REST contra mi PowerServer basado en .NET 8, del que ya os hablé en estos artículos:

https://rsrsystem.blogspot.com/2025/05/mi-power-server-porque-las-malas.html

y

https://rsrsystem.blogspot.com/2026/02/mi-cloud-framework-cuando-las-malas.html

La arquitectura es sencilla:

PowerBuilder
|
| WebBrowser + JavaScript
|
Consulta SQL Asistida
|
| REST JSON
|
PowerServer .NET 8
|
| SnapObjects
|
Base de datos

El SELECT se codifica en Base64 y se envía al controlador Datawindow/Cargar.

El servidor ejecuta la consulta utilizando SnapObjects y devuelve el resultado en JSON.

En el cliente, un DataStore se construye dinámicamente a partir de esa respuesta.

Es decir, un único endpoint capaz de ejecutar consultas sobre la base de datos definida por el perfil del usuario.

¿Es una decisión que hay que analizar cuidadosamente? Evidentemente.

No es algo que expondría alegremente en Internet. En mi caso es una herramienta interna, con perfiles, autenticación y pensada para administración y desarrollo.

Pero para ese escenario concreto funciona realmente bien.

Los cambios de datos utilizan otro controlador independiente, SqlExecutor, donde las operaciones se realizan con SQL parametrizado y valores tipados.


Integración con los temas de PowerBuilder

Otro detalle que quería cuidar era que la web no viviera aislada de la aplicación.

Cuando se cambia el tema visual de PowerBuilder:

  • Flat Design Blue
  • Orange
  • Lime
  • Silver
  • Dark

la ventana comunica el cambio al visor.

El color principal del tema se inyecta mediante JavaScript utilizando variables CSS, y botones, sliders y checkboxes se adaptan automáticamente.

Con el tema Dark el cambio es completo:

  • editor con paleta oscura
  • rejilla oscura
  • menús
  • ventanas emergentes de filtros
  • barras de desplazamiento del WebView2

Todo utilizando CSS y color-scheme: dark.

El único detalle curioso es que WebView2 no se lleva demasiado bien con cambios dinámicos de tema mediante ApplyTheme. La solución fue sencilla: al cambiar de tema, la ventana se cierra y se abre automáticamente.

Como la consulta y la configuración se guardan, el usuario prácticamente ni lo nota.


Comunicación PowerBuilder - JavaScript

La comunicación entre ambos mundos sigue el mismo patrón que en otras ventanas WebBrowser que he desarrollado.

Desde JavaScript hacia PowerBuilder:

  • eventos registrados mediante RegisterEvent
  • llamadas desde JavaScript mediante window.webBrowser.asyncfun.prototype

Desde PowerBuilder hacia la web:

  • EvaluateJavascriptAsync
  • envío de información mediante JSON

Después de muchas pruebas y algún que otro cuelgue, hay dos reglas importantes:

  1. Salir del contexto del evento JavaScript utilizando Post antes de volver a llamar al WebView.
  2. Nunca enviar un argumento vacío a un evento que espera parámetros.

Pequeños detalles, pero marcan la diferencia.


¿Entonces AG Grid ya no?

Que nadie me malinterprete.

AG Grid sigue siendo mi elección para aplicaciones donde necesito:

  • agrupaciones complejas
  • totales
  • pivotes
  • análisis avanzado de datos

Es una librería espectacular.

Pero para un visor SQL genérico integrado en PowerBuilder, esta solución con HTML, JavaScript y CSS puro resulta mucho más práctica:

  • se despliega copiando una carpeta
  • se modifica editando ficheros
  • no necesita procesos de compilación
  • arranca inmediatamente

A veces modernizar no significa añadir más tecnología sino quitar la que sobra.

Como siempre, os recomiendo que descarguéis los proyectos en mi perfil de Github, ya que aquí pueden recibir actualizaciones y lo del Drive será una copia estática:


Enlaces y Descargas

PowerBuilder 2025 R2 (FrontEnd): github.com/rasanfe/PersonDemo03

API creada con SnapDevelop 2025 en .Net 8 (BackEnd): github.com/rasanfe/MyPowerServer




¡Nos vemos en el próximo artículo! Y recuerda: en PowerBuilder, los límites solo están en nuestra imaginación. 🚀

Comentarios