Migrazione controllata di Paradox e BDE verso MariaDB

Molte Delphi-applicazioni verticali sono nate con tabelle Paradox e con la Borland Database Engine (BDE), perché all’epoca era uno standard pragmatico: locale, rapido da avviare, con poca infrastruttura. Nella pratica questi sistemi spesso operano ancora in produzione – inclusi reporting, stampa di etichette, import/export, batch job, tabelle storiche e logiche speciali che nel tempo si sono “insinuate” nell’accesso ai dati. Per questo una migrazione non è solo un’esportazione dei dati, ma una ricostruzione controllata: modello dati, comportamento SQL, effetti collaterali nel codice e processi operativi devono essere considerati insieme.

MariaDB è spesso una scelta molto valida come piattaforma target quando si punta a un funzionamento multiutente robusto, transazioni pulite, backup centrali, replicazione, una gestione chiara dei permessi e la connettività per portali web, servizi o API REST. La sfida raramente è l’installazione del database – lo sforzo vero sta nel percorso di migrazione sicuro: come vengono trasferite correttamente tabelle, indici, primary key, set di caratteri, campi data, valori “vuoti” e relazioni referenziali, senza rompere la logica di dominio in esercizio?

Questo articolo descrive una procedura consolidata per migrare Paradox e BDE in MariaDB in modo controllato: tecnicamente fondato, a fasi e con focus sulla stabilità. L’obiettivo è una base sostenibile per ulteriori passi di modernizzazione – per esempio la dismissione di BDE, il passaggio a una dismissione di BDE con connettività nativa, una chiara architettura Layer-3, server REST e client multipiattaforma.

Perché la migrazione Paradox/BDE è più di un cambio di database

Paradox come formato di file e BDE come strato di accesso formano un sistema complessivo con peculiarità che non è consigliabile replicare 1:1 in MariaDB. Sintomi tipici nella quotidianità sono:

• Dipendenze poco trasparenti: gli statement SQL sono distribuiti (Form, DataModule, Report, SQL stringhe dinamiche), spesso senza governance centrale.
• Comportamenti “a sensazione”: certi filtri, ordinamenti o join funzionano per caso, perché Paradox/BDE è tollerante o effettua conversioni implicite di tipo.
• Limiti multiutente: lock basati su file, cali di performance in rete, problemi di locking con l’aumentare del volume dati.
• Rischi di manutenzione: dipendenze da BDE, driver obsoleti, deploy complessi su versioni moderne di Windows, temi 64‑bit/ARM64.

Una migrazione controllata non tratta questi punti come effetti collaterali, ma come criteri d’obiettivo. MariaDB diventa non solo la “nuova banca dati”, ma l’occasione per disaccoppiare lo strato di accesso ai dati, aumentare l’integrità di dominio e rendere l’applicazione interoperabile.

Immagine di riferimento: MariaDB come base dati stabile per desktop, servizi e portali

Un’immagine di riferimento sensata per applicazioni B2B si compone di solito di tre livelli:

• Database (MariaDB): conservazione dati consistente, indici, vincoli, transazioni, utenti/ruoli, backup.
• Logica di dominio (Server/Services): validazioni, workflow, importer, scheduler, interfacce. Opzionalmente come REST-Server, Windows- o Linux-Services.
• Client (VCL/FMX/Web): interfacce utente, report, componenti offline, integrazioni. Idealmente con contratti chiari verso la logica di dominio.

In base alla situazione di partenza non tutto deve essere realizzato subito. Tuttavia la migrazione dovrebbe essere pianificata in modo da non precludere il percorso verso un’architettura pulita. Chi copia oggi solo le tabelle e domani continua a leggere/scrivere “direttamente” dal singolo form può avere MariaDB installata, ma i rischi reali restano invariati.

Inventario: cosa deve essere effettivamente migrato

All’inizio va fatta un’inventariazione che vada oltre il mero “quante tabelle”. Nei progetti Paradox/BDE è tipico che il database sia solo una parte della verità. Punti importanti:

1) Tabelle, indici, “pseudo-chiavi”

Spesso mancano chiavi primarie reali. Al loro posto esistono combinazioni di campi, numeri progressivi senza vincoli univoci o campi “Key” gestiti dall’applicazione. In MariaDB questi devono diventare chiavi univoche e affidabili – altrimenti transazioni e integrità referenziale avranno efficacia limitata.

2) Query, componenti SQL dinamico, report

BDE usa a seconda del componente dialetti SQL differenti e tollera statement “creativi”. Le componenti di reporting (anche più datate) contengono spesso SQL propri. Una migrazione deve trovare e categorizzare queste sorgenti: query core critiche, report poco usati, importazioni speciali.

3) Set di caratteri e caratteri speciali (Umlaut, ISO/ANSI, Unicode)

Molte applicazioni Paradox sono storicamente basate su ANSI. Se l’applicazione Delphi è stata in seguito portata a Unicode si creano mondi misti: dati in encoding vecchio, UI in Unicode, esportazioni che si aspettano Windows-1252. MariaDB dovrebbe ricevere qui un concetto chiaro (tipicamente utf8mb4), includendo una conversione pulita e test su errori “invisibili” (confronti, ordinamento, trim/pad, caratteri speciali).

4) Valori “vuoti”, logica NULL e campi data

Paradox/BDE conosce vari casi speciali: stringhe vuote al posto di NULL, date a 0, timestamp “vuoti”, valori di default creati dalla UI. MariaDB distingue rigidamente fra NULL e vuoto. Questo influenza clausole WHERE, aggregazioni e calcoli. Le differenze devono essere valutate per tabella/campo.

5) Artefatti laterali: tabelle di sessione, configurazioni locali, cache

Spesso nella struttura Paradox sono presenti tabelle locali per risultati intermedi, buffer di esportazione, layout utente o parametri. Alcuni elementi devono rimanere locali (es. layout UI), altri devono essere centralizzati (es. processi di lavoro, stati, log). La migrazione è l’occasione per separare queste categorie in modo chiaro.

Pitfall di Paradox/BDE: differenze tecniche tipiche

Per rendere la migrazione pianificabile conviene affrontare esplicitamente le differenze ricorrenti.

Dialetto SQL e operatori

BDE/Paradox-SQL non è identico al SQL di MySQL/MariaDB. Le differenze emergono, tra l’altro, nelle funzioni di data, nelle funzioni stringa, negli outer join (storici), nella logica di LIKE/maschere e nelle conversioni implicite di tipo. Un approccio controllato sostituisce il “funziona così” con regole chiare: quali statement vengono portati, quali riscritti deliberatamente, quali incapsulati in view/stored procedure (se sensato).

Ordinamento e collation

In Paradox l’ordine di ordinamento e il case-sensitivity spesso differiscono rispetto a MariaDB, in particolare per gli Umlaut. In MariaDB la collation (es. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) determina confronto e ordinamento. Non è una questione puramente teorica: influisce su deduplicazione, funzioni di ricerca e sul comportamento dei vincoli unici.

Autoincrement e numerazioni di dominio

Paradox dispone di campi autoincrement, ma le applicazioni spesso usano numerazioni proprie (numeri documento, numeri ordine) con logiche speciali. In MariaDB si dovrebbe separare con chiarezza:

• Chiave primaria tecnica: AUTO_INCREMENT (o UUID, secondo l’architettura) per le relazioni.
• Numero di dominio: numerazione gestionale separata con protezione transazionale, eventualmente per mandante/periodo.

Chi cerca di usare un numero di dominio come chiave tecnica si espone a ristrutturazioni costose in seguito.

Locking e transazioni

Il passaggio da accesso basato su file a un server vero è un vantaggio, ma cambia il comportamento. In MariaDB le transazioni (InnoDB) sono centrali. Bisogna decidere dove collocare i confini delle transazioni: per dialogo, per singola operazione di salvataggio, per batch. Particolarmente critico: nelle ambienti Paradox sono frequenti transazioni lunghe e modalità di “edit” che durano minuti; sul server ciò può causare lock prolungati, deadlock e lag di replica. Spesso l’adattamento delle modalità operative o dell’UI fa parte della migrazione.

Modello operativo: migrazione controllata a tappe invece del Big Bang

Negli ambienti B2B la stabilità operativa è spesso più importante di un taglio rapido. Un percorso di migrazione graduale riduce il rischio perché il business e l’IT possono validare iterativamente.

Fase 1: trasferimento modello dati con mapping, senza rifattorizzazione del codice

Nel primo passo si costruisce uno schema MariaDB che riproduce la struttura Paradox – ma già secondo i principi target: primary key, indici, tipi dati sensati, utf8mb4, InnoDB. Parallelamente si crea un processo di import ripetibile (script/tool) che può essere eseguito più volte. Qui la ripetibilità è cruciale, perché la migrazione raramente è “completa” al primo tentativo.

I deliverable tipici di questa fase sono:

• Definizione schema (DDL) versionata (es. in Git)
• Lista di field-mapping (Paradox → MariaDB) incluse regole di conversione
• Procedura di import con logging (conteggio record, errori, outlier)
• Primi report di validazione (counts, somme, checksum)

Fase 2: dismissione di BDE nell’accesso ai dati (es. con FireDAC)

Il vero passo di modernizzazione è il disaccoppiamento da BDE. Nei progetti Delphi BDE-Ablosung mit nativer Anbindung è una via consolidata, perché offre driver moderni, transazioni, binding di parametri e componenti uniformi per diversi backend SQL. Non conta solo “togliere BDE”, ma come il codice appare dopo: accesso dati centralizzato, gestione chiara degli errori, parametri puliti invece di concatenazioni di stringhe.

Attività tipiche in questa fase:

• Sostituzione di TTable/TQuery con query e DataSet basati su FireDAC
• Introduzione di uno strato di Data-Access (DAL) come base per una futura architettura Layer-3
• Standardizzazione degli ambiti transazionali (Commit/Rollback)
• Review SQL: adeguamento dialetto, parametri, paging, join

Se l’applicazione è destinata a una modernizzazione a lungo termine, questa tappa è spesso più rilevante della sola migrazione dati. Crea la libertà tecnica per 64‑bit, versioni moderne di Windows e pipeline di deployment pulite.

Fase 3: esercizio in parallelo e collaudo funzionale senza interruzioni operative

Per sistemi critici è sensato far funzionare i due ambienti in parallelo: MariaDB viene popolata ciclicamente (o incrementale) mentre il sistema legacy prosegue. Così il business può confrontare report, identificare casi limite e testare la nuova piattaforma sotto carico. Il funzionamento parallelo può essere attuato in vari modi:

• Replica in sola lettura per reporting/preparazione BI
• “Dual Write” in aree definite (solo se ben governato)
• Migrazione a data cut con più dry-run e checklist di cutover

È importante non complicare eccessivamente la soluzione: il Dual-Write è attraente ma incline a errori se la logica di dominio non è centralizzata. Spesso un cut ripetibile con validazione accurata risulta più economico.

Fase 4: ottimizzazione, integrità, performance, processi operativi

Dopo il cutover inizia la fase in cui MariaDB deve giocare i suoi punti di forza: integrità referenziale, indici performanti, permessi chiari, monitoring, test di backup/restore. È qui che emergono spesso i carichi reali di produzione: report lunghi, maschere di ricerca con scarsa indicizzazione, aggiornamenti batch. Una migrazione controllata pianifica esplicitamente questa fase invece di lasciarla come lavoro posticipato non previsto.

Tipi dati e mapping: da Paradox a MariaDB senza perdita informativa

Il mapping dei campi è il cuore della migrazione. Assegnazioni tipiche (semplificate) sono:

• Alpha / Memo: VARCHAR/TEXT (con utf8mb4), controlli di lunghezza e regole di trim
• Number: INT/BIGINT/DECIMAL a seconda dell’intervallo; attenzione ai decimali impliciti
• Date/Time: DATE/DATETIME/TIMESTAMP; regole chiare per “data 0” vs NULL
• Logical: BOOLEAN o TINYINT(1) con semantica univoca
• Currency: DECIMAL(…,2/4) al posto di float, per evitare errori di arrotondamento

È importante non limitarsi a tradurre i tipi, ma documentare anche le regole di dominio: un campo può essere NULL? Quali default sono corretti dal punto di vista funzionale? Quali combinazioni devono essere univoche? Da questo derivano vincoli e indici. Queste regole erano spesso implicite nel sistema Paradox/BDE nella UI o nel codice – in MariaDB dovrebbero diventare esplicite dove sensato.

Integrità: riportare Primary Key, Foreign Key e indici unici

Molti database legacy funzionano per anni senza integrità referenziale – fino a quando non arrivano integrazioni, portali o processi paralleli. A quel punto la qualità dei dati diventa fattore limitante. In MariaDB è possibile applicare Foreign Key, Unique Constraint e CHECK (a seconda di versione/engine) per prevenire errori dati precocemente.

Un approccio praticabile è introdurre l’integrità a step:

• Prima le Primary Key e indici unici sugli oggetti core (clienti, articoli, documenti)
• Poi le Foreign Key nelle aree stabili
• Per tabelle “storiche” con dati sporchi: prima pulizia, poi applicazione di vincoli

Questo riduce il rischio che il cutover fallisca a causa di zavorre legacy e migliora comunque la situazione complessiva.

Performance nella pratica: cosa cambia con MariaDB

I sistemi Paradox/BDE sono spesso ottimizzati per la “velocità file”: indici locali, accessi tabella rapidi, molta filtrazione lato client. Con MariaDB il lavoro si sposta sul server. È un vantaggio, ma richiede strategie SQL e di indice pulite.

Trappole tipiche di performance

• SELECT * da tabelle grandi, perché prima “locale” era abbastanza veloce
• Filtri lato client invece di WHERE lato server
• Mancanza di indici composti su campi di ricerca (es. mandante + stato + data)
• LIKE ‚%testo%‘ senza una strategia fulltext adeguata

Migliorare in modo misurabile invece di “a sensazione”

Una migrazione controllata stabilisce presto punti di misura: Slow Query Log, analisi Explain, test di carico riproducibili. Questo è particolarmente importante se dopo la migrazione sono previsti componenti aggiuntivi, come un REST-Server o un Kundenportal, che cambiano i pattern di accesso (molte richieste piccole, paging, endpoint di ricerca).

Delphi-specifico: dismissione di BDE, FireDAC e layer di accesso puliti

Nei progetti Delphi la modernizzazione tecnica è strettamente legata all’accesso ai dati. BDE non è solo “un driver”, ma uno stile di accesso completo (TTable, basato su record, navigazione, filtri locali). La migrazione a MariaDB è il momento giusto per consolidare l’accesso.

Da “DataSet ovunque” a accesso dati controllato

Molte applicazioni hanno query proprie in ogni form. Questo scala male sia funzionalmente che a livello di sicurezza. Una transizione efficace prevede:

• Classi repository/service centrali per oggetti core
• Gestione uniforme di errori e transazioni
• Query parametrizzate (evitare SQL injection, sfruttare plan-caching)
• Pool di connessione configurabili o gestione delle connessioni per i servizi

Questo crea la base per una architettura Layer-3 dove UI, logica di dominio e persistenza sono separati. Aiuta non solo nel cambio di database, ma anche nella successiva evoluzione verso REST-Server o servizi background.

Connessione MariaDB con FireDAC: punti da definire

Nei progetti ricorrono sempre le stesse domande: quale variante di driver (MySQL/MariaDB), quali opzioni SSL, quali impostazioni di timezone e data, quali set Unicode? Non sono dettagli secondari, perché incidono direttamente sulla consistenza dei dati (data/ora), sull’ordinamento e sulla sicurezza operativa (TLS). Una migrazione controllata fissa questi parametri, li documenta e li testa con dati realistici.

Piano di Cutover: data decisiva, freeze dati, rollback – senza sorprese

Il cutover è un progetto a sé. Un buon piano di cutover descrive non solo “quando commutare”, ma anche le misure di protezione:

• Dati congelati: da quando nel sistema legacy non vengono più registrati dati? Esistono processi di emergenza?
• Import finale: quanto dura realisticamente? (i dry-run forniscono stime.)
• Validazione: quali controlli devono essere verdi prima del go-live (conteggi, somme, campionature, report funzionali)?
• Rollback: quando si abbandona e come si procede?
• Comunicazione: chi autorizza? chi è reperibile nel war room?

Nel mondo delle medie imprese un “rollback” è spesso critico più dal punto di vista organizzativo che tecnico. Per questo la migrazione va preparata in modo che il cutover non sia un esperimento, ma una procedura già provata.

Dopo la migrazione: base per REST, servizi e multiplatform

Quando MariaDB è stabile e la dismissione di BDE è stata eseguita correttamente, si aprono nuove opzioni: API REST per sistemi esterni, elaborazione in background come servizi Windows o Linux, disaccoppiamento tra UI e logica di dominio e, prospetticamente, client multipiattaforma. Molto spesso il passo successivo è estrarre la logica di dominio dal desktop per servire integrazioni (ERP/DMS/CRM) e portali in modo controllato.

È importante: un REST-Server non è uno “strato in più”, ma una decisione architetturale. Chi ha già consolidato accesso ai dati, validazioni e autorizzazioni in servizi/repository potrà esporre API robuste con molta più facilità.

Checklist pratica: cosa chiarire prima dell’avvio del progetto

• Quali moduli sono business-critical e devono essere operativi al cutover?
• Quali sono i volumi reali di dati (dimensione tabelle, crescita, concetti di archiviazione)?
• Quali report devono essere identici 1:1 e quali possono essere migliorati?
• Quali integrazioni dipendono dal sistema (esporti file, ODBC, Office, flussi di stampa)?
• È presente multi-tenancy e, se sì, come è rappresentata oggi?
• Quali requisiti operativi valgono (finestra di backup, RTO, permessi, audit)?

Queste chiarificazioni non sono burocrazia, ma evitano che una migrazione sia “tecnicamente completa” ma non accettata funzionalmente.

Conclusione: migrare in modo controllato significa rendere i rischi pianificabili

Migrare Paradox e BDE in MariaDB in modo controllato significa modernizzare l’applicazione come sistema complessivo: modello dati, SQL, transazioni, set di caratteri, layer di accesso e processi operativi. Chi vede il cambio come un semplice export ottiene spesso esattamente i problemi che voleva eliminare – soltanto su un nuovo server.

Un approccio a tappe con import ripetibile, mapping di campo preciso, validazione precoce e una chiara dismissione di BDE (es. tramite FireDAC) crea invece una base stabile: per il multiutente, per integrazioni, per servizi e per i prossimi passi della Delphi Modernisierung.

Se volete pianificare la vostra migrazione in modo professionale e senza interruzioni operative, discutiamo volentieri la situazione di partenza, i rischi e un piano a fasi realistico: https://net-base-software-gmbh.de/kontakt/