Free PlyxSQL ETL - 1.0.0.90

Free PlyxSQL© Beta - 1.0.0.90  - ETL

POSTED BY Giuliano pagnini, 15 AGO 2026

Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml

PlyxSQL ETL: un uragano di potenza tra le tue tabelle

Il cuore del motore: una regola per campo, nessun compromesso
1. Diretto — la base, ma con un asso nella manica
C'è un momento, in ogni progetto dati, in cui un semplice "copia da A a B" non basta più. Serve pulire un campo, tradurre un codice, combinare due colonne, decidere riga per riga cosa scrivere e cosa no, ripetere tutto ogni notte alla stessa ora senza che nessuno debba ricordarsene. È esattamente lì che entra in scena il motore ETL di PlyxSQL: non un semplice "copia dati", ma un sistema a fasi con un arsenale di regole capace di trasformare, filtrare, arricchire e sincronizzare qualunque sorgente — Firebird, SQL Server, CSV, o un connettore REST come Google Calendar — verso qualunque destinazione.
Vediamo perché, quando si scatena, è davvero un uragano.
Ogni campo mappato in una fase ETL di PlyxSQL può usare una regola diversa. Non un'unica trasformazione globale forzata su tutta la tabella: sette regole indipendenti, scelte campo per campo.

Copia il valore così com'è dalla sorgente alla destinazione. Semplice, sì, ma con una Quick Action opzionale per una pulizia last-minute senza aprire un editor di espressioni: rimuovi un simbolo di valuta, sostituisci un frammento di testo, forza maiuscolo/minuscolo, elimina gli spazi superflui. Il tocco finale prima che il valore atterri a destinazione.

2. Costante — lo stesso valore, per ogni riga

Un campo destinazione che deve sempre valere "IMPORTATO", o un flag fisso, o un codice sorgente identico su tutte le righe: la regola Costante lo scrive senza bisogno di leggere nulla dall'origine.

3. Espressione — il vero motore di trasformazione

Qui la potenza sale di livello. Un mini-linguaggio di funzioni pronte all'uso, applicabile a qualunque campo:

• UPPER, LOWER, TRIM — normalizzazione testo immediata
• LEFT(n) / RIGHT(n) — estrazione di sottostringhe
• DEFAULT(valore) — un paracadute per i null
• CONST(valore) — un valore fisso via espressione
• REGEXMATCH(pattern) — valida (o scarta) in base a un pattern
• REGEXEXTRACT(pattern) — cattura solo ciò che serve da un testo sporco
• REGEXREPLACE(pattern;sostituzione) — sostituzioni avanzate con gruppi catturati ($1, $2...)
• DATE(formato) — trasforma una stringa CSV in un vero TDateTime
• NUMBER(decimale;migliaia) — interpreta numeri con qualunque convenzione regionale
• RFC3339 — converte una data/ora reale nel formato testuale richiesto da API REST come Google Calendar (2026-08-10T14:32:07.000Z)

E per chi non vuole ricordare la sintassi a memoria, c'è un assistente visivo che elenca tutte le funzioni disponibili, i parametri richiesti, e mostra l'anteprima live del risultato.

4. Formula — quando un campo solo non basta

La regola Formula combina più campi origine in un unico valore, con segnaposto liberi tra testo e separatori:

{VIA} {NOME}          →  "Via Rossi"
{DATA:yyyy-mm-dd}T{ORA:hh:nn:ss}.000Z   →  timestamp RFC3339 per un evento calendario

Ogni segnaposto può portarsi dietro un formato specifico ({DATA:yyyy-mm-dd}), così due colonne data e ora separate diventano un unico blocco testuale pronto per qualsiasi API.

5. Lookup — la traduzione intelligente

Serve tradurre un codice cliente in ragione sociale, o un CAP in nome comune? La regola Lookup cerca il valore in un'altra tabella — origine o destinazione, a scelta — e supporta:

• chiavi composite (più campi combinati per la ricerca)
• una espressione di pulizia applicata alla chiave PRIMA della ricerca (es. estrarre "Via Emilia" da "Via Emilia, 87" con una REGEXEXTRACT mirata)
• un valore di default quando la corrispondenza non viene trovata

6. AutoIncrementale — contatori sempre coerenti

Assegna un numero progressivo a ogni riga scritta in questa esecuzione. Due modalità: si parte da un valore fisso, oppure si riparte automaticamente da MAX(campo)+1 letto dalla tabella di destinazione — mai duplicati, mai buchi da gestire a mano.

7. Ignora — il controllo è anche saper escludere

Un campo mappato ma esplicitamente escluso dalla scrittura: utile per tenere traccia della corrispondenza senza inquinare la destinazione.

Condizioni: la regola si applica solo se vuoi tu

Ogni singolo campo — qualunque sia la regola scelta — può essere subordinato a una condizione "Esegui regola solo se", con diciotto tipi di condizione pronti all'uso: vuoto/non vuoto, solo cifre, solo lettere, alfanumerico, inizia con / contiene / termina con, uguale/diverso, confronti di lunghezza testo, confronti numerici, corrispondenza a un pattern regolare — ciascuna negabile con un semplice flag.

E quando la condizione è falsa? Non un semplice "salta e basta": puoi scegliere cosa scrivere in alternativa — un valore fisso, il contenuto di un altro campo origine, o persino un'intera Formula multi-campo per il ramo "altrimenti". Una logica condizionale completa, riga per riga, senza scrivere una riga di codice.

La gestione a fasi: dove la potenza diventa struttura

Ogni fase ETL è una coppia tabella-origine → tabella-destinazione, e porta con sé un intero pannello di controllo:

• Cinque modalità di scrittura (BatchMove): Inserisci sempre, Aggiungi nuovi, Aggiorna esistenti, Aggiungi/aggiorna (upsert) ed Elimina — ognuna pensata per uno scenario diverso, dalla prima importazione alla sincronizzazione incrementale quotidiana.
• Pulizia prima dell'importazione (ClearBefore) o SQL personalizzato eseguito prima e dopo la fase, per preparare il terreno o rifinire il risultato.
• Filtro WHERE sulla sorgente, o addirittura una query SQL personalizzata al posto della semplice tabella, per estrarre esattamente le righe che servono.
• Formati di default per fase: imposta una volta il formato data o il separatore decimale e si applica automaticamente a tutti i campi Diretto della fase, senza ripetere DATE(...) o NUMBER(...) campo per campo.
• Connessioni per-fase: ogni fase può sovrascrivere la connessione origine/destinazione globale del progetto — utile quando un progetto ETL unico deve leggere da un database e scrivere su più destinazioni diverse (o viceversa).
• Scrittura verso il mondo reale: per le destinazioni basate su connettore (CSV, LocalSQL, REST come Google Calendar/Sheets), il motore scrive prima in una rappresentazione locale ad altissima velocità e poi effettua il "flush" reale — file o chiamata HTTP — al termine della fase, così anche migliaia di righe volano senza appesantire ogni singola scrittura di una latenza di rete.
• Diagnostica integrata: in caso di errore di scrittura, il motore confronta automaticamente i tipi di colonna della destinazione con i valori che ha provato a scrivere, e ti dice — riga per riga — la causa più probabile, invece di lasciarti un generico errore SQL da decifrare.

Il motore sotto il cofano: TFDBatchMove, dove la velocità diventa potenza

Tutto quello che abbiamo visto finora — regole, condizioni, formule — sarebbe inutile se, riga dopo riga, la scrittura fosse lenta. Ed è qui che PlyxSQL ETL fa una scelta tecnica precisa: non scrive mai una riga alla volta.

Ogni fase trasforma i dati in uno staging in memoria , e da lì un solo oggetto TFDBatchMove per fase si occupa di travasarli verso la destinazione a blocchi, usando Array DML di FireDAC invece di una ExecSQL() per singolo record. Concretamente significa che il driver non apre e chiude un'istruzione SQL per ogni riga, ma impacchetta interi lotti di righe in un'unica operazione a basso livello verso il database — lo stesso principio con cui un TIR trasporta un container invece di mille furgoncini in fila.

I numeri dietro le quinte:

• Blocchi da 500 righe di default (CommitCount), configurabili: una singola transazione per ogni blocco scaricato, non una transazione per riga — meno overhead, meno round-trip verso il database, commit molto più rapidi.
• Un solo TFDBatchMove per l'intera fase, non uno ricreato ad ogni blocco: l'oggetto viene semplicemente rieseguito (Execute()) più volte sullo stesso reader/writer già configurati, azzerando i costi di inizializzazione ripetuta.
• Le cinque modalità di scrittura (Inserisci sempre, Aggiungi nuovi, Aggiorna esistenti, Aggiungi/aggiorna, Elimina) girano tutte sullo stesso motore a blocchi: la potenza dell'Array DML non è riservata al semplice inserimento, ma resta piena anche negli scenari di sincronizzazione incrementale più complessi.
• Mapping automatico per nome colonna: lo staging usa già gli stessi nomi della tabella di destinazione, quindi TFDBatchMove genera da solo INSERT/UPDATE/DELETE senza bisogno di configurazioni manuali che rallenterebbero la fase di preparazione.
• Diagnostica senza perdita di velocità: se un blocco fallisce, il motore non deve rallentare l'intera fase per capire perché — confronta i tipi delle colonne di destinazione con i valori dello staging e produce una diagnosi mirata solo sul blocco incriminato, lasciando che tutto il resto continui a correre.

Il risultato è un motore che scala: che siano 11 righe o 11 milioni, TFDBatchMove è il pistone che trasforma tutte le regole di trasformazione viste finora in scritture reali sul database — a blocchi, in transazioni compatte, con la potenza di scrittura nativa di FireDAC invece della lentezza di un ciclo riga-per-riga.

E ancora: pianificazione e assistenza AI

Un progetto ETL di PlyxSQL non deve nemmeno essere lanciato a mano ogni volta: puoi pianificarlo — giornaliero, settimanale (con giorno della settimana), o mensile (con giorno del mese, gestione automatica dei mesi corti) — e lasciarlo girare da solo.

Servizio windows gestisce tutti i progetti pianificati (a richiesta)

E se stai iniziando da zero, non serve mappare ogni campo manualmente: il motore può generare automaticamente intere fasi confrontando le tabelle omonime tra due connessioni e proponendo il mapping diretto già pronto per i campi corrispondenti — e un bridge AI opzionale può persino suggerire le corrispondenze quando i nomi dei campi non coincidono esattamente, inviando solo i nomi dei campi (mai i dati reali) al modello configurato.

Il risultato

Sette regole di campo componibili, condizioni con rami alternativi, cinque modalità di scrittura sostenute da un motore a blocchi con Array DML, filtri e SQL personalizzati, formati di default, connessioni multiple per progetto, pianificazione automatica e generazione assistita: non un semplice importatore, ma una vera centrale di trasformazione dati — capace di prendere qualsiasi sorgente e scatenarla, blocco dopo blocco, esattamente dove e come serve, alla velocità che solo TFDBatchMove può dare.

Un uragano, sì. Ma un uragano che segue esattamente le regole che gli dai.

#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL