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

Free PlyxSQL© SQL Beta - 1.0.0.90 - Text to SQL

Free PlyxSQL© Beta - 1.0.0.90  - Text to SQL

POSTED BY Giuliano pagnini, 15 AGO 2026

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

PlyxSQL apre le porte a centinaia di servizi: arriva il connettore generico OAuth2 (Rilascio fine agosto)

C'è un momento, in ogni strumento pensato per lavorare con i dati, in cui la vera domanda smette di essere "quanto è potente il motore?" e diventa "con quante cose riesce a parlare?". Un database, per quanto solido, vale poco se resta isolato: i dati veri oggi vivono sparsi tra CRM, fogli di calcolo condivisi, form di contatto, servizi di produttività, database web-based. PlyxSQL risponde a questa domanda con una novità che cambia le regole del gioco: il connettore generico OAuth2.

Non è un nuovo connettore. È un motore per crearne quanti ne servono, senza scrivere una riga di codice.

Semplice crea una cartella sotto connettori con il json di configurazione e icona e sei pronto per usare con i dati del servizio

Il problema che risolve

Fino a ieri, collegare PlyxSQL a un servizio esterno significava — nella migliore delle ipotesi — aspettare che qualcuno implementasse quell'integrazione specifica. Ogni servizio con la sua autenticazione, il suo formato di risposta, le sue regole di paginazione: un lavoro di sviluppo dedicato per ogni singolo collegamento, moltiplicato per decine di piattaforme diverse.

Il connettore generico OAuth2 ribalta l'approccio. Invece di un connettore per servizio, PlyxSQL offre un motore che legge la descrizione di un servizio — un semplice file di configurazione — e sa già come autenticarsi, interrogare le API, trasformare le risposte in tabelle interrogabili con SQL. Aggiungere un nuovo servizio non è più un progetto: è compilare un modello.

I punti di forza

1. Zero codice per ogni nuova integrazione. Descrivere un servizio richiede solo un file di configurazione con gli URL delle API e i campi da mappare: l'endpoint di autorizzazione, l'endpoint del token, e la lista degli endpoint da esporre come tabelle. Il motore fa il resto — dal login OAuth2 completo (incluso PKCE, per chi non vuole gestire client secret) al refresh automatico dei token scaduti.

2. Copertura potenzialmente enorme. Qualsiasi servizio che espone API REST protette da OAuth2 diventa, in linea di principio, una fonte dati per PlyxSQL: CRM, strumenti di marketing, piattaforme di produttività, servizi cloud, database web-based con API pubbliche. Non centinaia di connettori scritti a mano — centinaia di configurazioni possibili, scritte da chiunque abbia bisogno di un'integrazione specifica.

3. Le tabelle vere, non solo "letture" statiche. Ogni endpoint configurato diventa una tabella sfogliabile nell'albero delle connessioni, con supporto nativo a paginazione automatica (sia con token di pagina che con URL di continuazione), fetch di dettaglio riga-per-riga quando una API restituisce solo elenchi sommari, e persino scrittura: alcune tabelle possono diventare destinazioni di una fase ETL, con push automatico dei dati verso l'API remota a fine elaborazione.

4. "Sfoglia e connetti", non solo "configura e spera". Per i servizi che organizzano le risorse in gerarchie — un foglio di calcolo con le sue schede, uno spazio di lavoro con le sue tabelle — il connettore generico supporta un resource picker: un'interfaccia che lascia scegliere la risorsa giusta da un elenco reale, invece di andare a copiare ID a mano dalla barra degli indirizzi del browser.

5. Le chiavi restano dell'utente, sempre. Ogni credenziale — client ID, token, ID di risorsa — è un valore personale configurato una sola volta e mai incorporato nella definizione del connettore. La configurazione descrive come parlare con un servizio; le chiavi di chi sta parlando restano separate, cifrate e locali.

6. Non serve nemmeno l'OAuth2, se non serve. Alcuni servizi non hanno bisogno di un flusso di autorizzazione completo — un semplice endpoint pubblico, o una API key statica, bastano. Il motore riconosce anche questi casi, senza forzare un login inutile dove non è richiesto: la stessa filosofia di "descrivi il servizio, non scrivere codice" si applica a un ventaglio più ampio di scenari di autenticazione.

Perché conta davvero

La differenza tra un prodotto con dieci integrazioni e uno con centinaia non è solo di quantità. È di chi decide cosa collegare. Con un motore generico, non serve aspettare una roadmap: se un servizio espone API ragionevoli, l'integrazione può nascere lo stesso giorno in cui serve, scritta da chi la usa, condivisa con chiunque altro ne abbia bisogno.

PlyxSQL smette così di essere "un client SQL con qualche connettore in più" e diventa un punto di incontro reale tra i dati strutturati di un database e il caos — spesso utilissimo — dei servizi web che oggi ospitano la maggior parte delle informazioni con cui lavoriamo ogni giorno.

Il connettore generico OAuth2 è disponibile da oggi in PlyxSQL. La cartella dei connettori pronti all'uso continuerà a crescere — e chiunque può contribuirne di nuovi.

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