4.1HFSQL Client/Serveur: instalación y administración
Lo esencial en 30 segundos
- En CLIENT/SERVEUR, un servidor centraliza los datos: las aplicaciones le envían consultas, él las procesa y solo devuelve los resultados — tráfico de red mínimo, rendimiento y robustez en multiusuario, seguridad y accesos remotos.
- Buena noticia para la migración: el ANÁLISIS no cambia y el código WLangage sigue siendo en gran medida idéntico (las funciones H funcionan en ambos modos); lo esencial del trabajo está en la instalación, la migración de los datos y la conexión.
- Dos conceptos clave: las TRANSACCIONES (todo o nada) y el BLOQUEO (accesos concurrentes); ⚠️ un servidor de datos exige una administración real: supervisión, actualizaciones y, sobre todo, copias de seguridad automatizadas Y PROBADAS.
Minicaso continuo — Yacine pasa su comercio a HFSQL Client/Serveur
Yacine, desarrollador WinDev en una pyme de comercio de material eléctrico en Orán, ha construido una aplicación de gestión (clientes, productos, pedidos, facturas, stocks). Funciona en HFSQL Classic: los archivos de datos están en un recurso compartido de red y cada puesto los lee directamente. Con seis usuarios (comerciales, almacenero, contable) trabajando al mismo tiempo, las lentitudes empeoran en las horas punta, y un corte de red durante la introducción de un pedido dejó un stock descontado sin pedido correspondiente: una incoherencia silenciosa. Yacine decide pasar a HFSQL Client/Serveur: instala el servidor HFSQL en una máquina dedicada, migra los datos desde Classic, crea los usuarios y sus derechos en el servidor y configura la conexión en la aplicación. Retiene dos reflejos: envolver la operación «pedido + líneas + stock» en una transacción corta (todo o nada) y gestionar los bloqueos entre usuarios. Por último, implanta copias de seguridad automatizadas, almacenadas en otro lugar, y prueba una restauración real. Anota el principio: el análisis no cambia, el código H sigue igual; el trabajo está en la instalación, la migración y la conexión.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el guion y el reto de 48 h de la sección 4.1.
1. Un servidor que centraliza
Pasar a HFSQL Client/Serveur cambia la arquitectura. En Classic, cada puesto lee directamente los archivos de datos del disco local o de un recurso compartido de red; en Client/Serveur, un servidor centraliza todo: las aplicaciones le envían consultas, él las procesa y solo devuelve los resultados. Los beneficios son importantes: el tráfico de red se reduce drásticamente (solo circulan los datos útiles), los accesos concurrentes los gestiona el motor, el riesgo de corrupción disminuye mucho, la seguridad (autenticación, derechos, cifrado) es posible y los accesos remotos (teletrabajo, agencias) son por fin fiables. En administración: supervisión, copias de seguridad incluso en caliente y mantenimiento centralizado.
2. Instalar, migrar, conectar
En la práctica hay que instalar y administrar el servidor. (1) Instalación del servidor HFSQL en una máquina correctamente dimensionada (procesador, memoria, disco). (2) Creación de las bases y migración de los datos desde Classic. (3) Gestión de los usuarios y derechos en el servidor (quién puede leer, escribir, administrar). (4) Configuración de la conexión en la aplicación (servidor, puerto, credenciales). Buena noticia para la migración: como el análisis no cambia y el código WLangage sigue idéntico, lo esencial del trabajo se concentra en estas etapas.
3. Transacciones y bloqueo
Dos conceptos que hay que dominar. Las transacciones garantizan que un conjunto de escrituras se realiza por completo o no se realiza: registrar un pedido consiste en crear la cabecera, las líneas, decrementar el stock y actualizar el total del cliente; si se produce una interrupción a mitad, se obtiene un pedido sin líneas o un stock descontado sin pedido. La transacción evita ese estado incoherente silencioso y gestiona el aislamiento entre usuarios. El bloqueo gestiona el caso en que dos usuarios modifican el mismo registro: impedir la modificación concurrente (pesimista) o detectar el conflicto al guardar (optimista); lo esencial es que ninguna modificación se sobrescriba silenciosamente (la «actualización perdida»). Mantenga las transacciones cortas: nunca deje una transacción abierta esperando una introducción de datos.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Conexión y transacción
El esqueleto de una aplicación pasada a Client/Serveur, como la de Yacine:
// 1) Connexion au serveur HFSQL de la PME (Oran)
SI HOpenConnection("CnxNegoce", "srv-oran", "yacine", sMdp, hOuvre) = VRAI ALORS
HChangeConnection("*", "CnxNegoce")
SINON
Erreur("Serveur HFSQL injoignable : " + HErreurInfo())
FIN
// 2) Enregistrer une commande : TOUT OU RIEN
HTransaction("CnxNegoce")
SI HAjoute(Commande) ET HAjoute(LigneCommande) ALORS
HTransactionFin("CnxNegoce") // validé : tout est définitif
SINON
HTransactionAnnule("CnxNegoce") // annulé : rien n'est écrit
FINLectura: el servidor se designa por su nombre y la conexión se convierte en la referencia para todas las funciones H de la aplicación.
Lección: la transacción envuelve la operación de negocio «pedido + líneas + stock»: o se escribe todo o no se escribe nada — nunca una incoherencia silenciosa.
Vocabulario de la sección
- Arquitectura Client/Serveur
- Un servidor centraliza los datos: las aplicaciones le envían consultas, él las procesa y solo devuelve los resultados.
Ejemplo sencillo: Yacine instala un servidor HFSQL para su comercio de seis puestos.
Lo que no es: el modo Classic, en el que cada puesto lee directamente los archivos.
Reflejo: centralizar y fiabilizar → el Client/Serveur.
- Migración desde Classic
- Paso a Client/Serveur: el análisis no cambia y el código WLangage sigue siendo en gran medida idéntico — el trabajo está en la instalación, la migración de los datos y la conexión.
Ejemplo sencillo: Yacine migra sus datos Classic al servidor sin retocar su análisis.
Lo que no es: una reescritura completa de la aplicación.
Reflejo: cambiar de arquitectura sin reescribirlo todo → la migración.
- Transacción
- Garantizar que un conjunto de escrituras se realiza por completo o no se realiza (pedido + líneas + stock, nunca uno sin el otro).
Ejemplo sencillo: Yacine envuelve la introducción del pedido en una transacción corta.
Lo que no es: cuatro escrituras independientes, cada una validada por separado.
Reflejo: operación compuesta → una transacción.
- Bloqueo (accesos concurrentes)
- Mecanismo que gestiona el caso en que dos usuarios modifican el mismo registro, para evitar que una modificación sobrescriba silenciosamente otra.
Ejemplo sencillo: Yacine gestiona el bloqueo entre dos comerciales sobre la misma ficha de cliente.
Lo que no es: dejar que dos puestos escriban sin control (actualización perdida).
Reflejo: evitar la actualización perdida → el bloqueo.
- Administración (⚠️)
- Un servidor de datos exige una administración real: supervisión, usuarios y derechos, actualizaciones y copias de seguridad automatizadas Y PROBADAS.
Ejemplo sencillo: Yacine automatiza sus copias de seguridad y restaura una para comprobarla.
Lo que no es: «instalar y olvidar», sin supervisión ni copia de seguridad.
Reflejo: un servidor se gestiona → la administración.
En la práctica — En la práctica — Implantar HFSQL Client/Serveur
- Instale el servidor HFSQL en una máquina correctamente dimensionada, luego cree la base y migre los datos desde el modo Classic, como Yacine.
- Configure los usuarios y sus derechos en el servidor (lectura, escritura, administración) y después configure la conexión en la aplicación.
- Utilice transacciones para las operaciones compuestas por varias escrituras vinculadas (todo o nada) y gestione correctamente los bloqueos entre usuarios.
- Implante copias de seguridad automatizadas, almacenadas en otro lugar, y pruebe una restauración — una copia de seguridad nunca probada no vale nada.
Guion paso a paso — pasar a Client/Serveur como Yacine (5 min)
1) Instale y dimensione el servidor HFSQL en una máquina dedicada. 2) Cree la base y migre los datos desde Classic. 3) Defina los usuarios y sus derechos en el servidor (lectura, escritura, administración). 4) Configure la conexión en la aplicación (servidor, puerto, credenciales). 5) Envuelva la introducción del pedido en una transacción corta y compruebe que un error anula realmente todas las escrituras. 6) Automatice las copias de seguridad, guárdelas en otro lugar y pruebe una restauración real.
El análisis y el código H no cambian: céntrese en la instalación, la migración, la conexión y la administración (copias de seguridad probadas).
Plantilla para copiar y pegar — mi ficha Client/Serveur
Classic : fichiers sur partage reseau, acces direct
Client/Serveur : serveur central, requetes -> resultats
Migration : analyse inchangee, code H identique
Connexion : serveur + port + identifiants (HOpenConnection)
Transactions : commande + lignes + stock = TOUT OU RIEN
Acces concurrents : gerer le BLOCAGE (eviter la MAJ perdue)
Administration : sauvegardes automatisees, stockees ailleurs ET TESTEESCambio Classic → C/S
Yacine migra los datos de su recurso compartido de red a un servidor HFSQL central.
Transacción corta
Yacine envuelve «pedido + líneas + stock» en una transacción todo o nada.
Bloqueo gestionado
Yacine impide que dos comerciales sobrescriban mutuamente la misma ficha de cliente.
Copia de seguridad probada
Yacine restaura una copia de seguridad en una máquina de prueba para comprobar que es utilizable.
✓ Buenas prácticas
- Migrar sin reescribir: el análisis y el código H no cambian.
- Mantener las transacciones cortas y gestionar el bloqueo de los accesos concurrentes.
- Automatizar las copias de seguridad y probar una restauración.
✗ Errores frecuentes
- Creer que pasar a C/S obliga a reescribirlo todo.
- Dejar Classic en un recurso compartido de red con muchos usuarios.
- Hacer copias de seguridad sin probar nunca la restauración.
Puntos clave
- En Client/Serveur, un servidor centraliza los datos y solo devuelve los resultados: rendimiento, robustez, seguridad y accesos remotos.
- La migración no cambia ni el análisis ni el código H: el trabajo está en la instalación, los datos y la conexión.
- Las transacciones (todo o nada) y el bloqueo (accesos concurrentes) garantizan la coherencia.
- ⚠️ Un servidor exige una administración real: supervisión, derechos, actualizaciones y copias de seguridad probadas.
Reto 48 h — aplícalo mañana
Como Yacine, haga el balance de su aplicación: ¿cuántos usuarios simultáneos, qué volúmenes, qué lentitudes? Si hay una señal para cambiar, instale un servidor HFSQL de prueba, migre una copia de los datos y configure la conexión. Envuelva después una operación compuesta (pedido + líneas + stock) en una transacción corta y provoque un error para comprobar que no queda ninguna escritura parcial. Termine con una copia de seguridad restaurada en una máquina de prueba.
- Sé cuándo pasar de HFSQL Classic a Client/Serveur.
- Instalo el servidor, migro los datos y configuro la conexión.
- Utilizo transacciones y bloqueos, con copias de seguridad probadas.
Preguntas frecuentes
¿Cuándo hay que pasar de HFSQL Classic a HFSQL Client/Serveur?
Pase a Client/Serveur en cuanto varios usuarios trabajen simultáneamente de forma intensiva (el criterio n.º 1), los volúmenes crezcan, necesite una seguridad fina o accesos remotos — Classic sigue siendo perfecto en monopuesto o para unos pocos puestos con uso ligero. Las señales: lentitudes crecientes en las horas punta, incidentes de corrupción, necesidad de derechos por usuario o de cifrado, teletrabajo. Buena noticia para la migración: el análisis no cambia y el código WLangage sigue siendo en gran medida idéntico. Se instala el servidor, se migran los datos y se actualizan los parámetros de conexión.
¿Por qué son indispensables las transacciones en multiusuario?
Porque una operación de negocio suele implicar varias escrituras que deben realizarse juntas. Registrar un pedido es crear la cabecera, crear las líneas, decrementar el stock y actualizar el total del cliente: cuatro escrituras para una sola operación. Sin transacción, un fallo o un corte después de la segunda escritura deja un pedido sin líneas o un stock descontado sin pedido — una incoherencia silenciosa, descubierta semanas más tarde. La transacción garantiza el todo o nada: se abre, se escribe y luego se valida o se anula. También gestiona el aislamiento entre usuarios y se articula con los bloqueos.
¿Por qué son indispensables las transacciones en HFSQL multiusuario?