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

Free PlyxSQL© SQL Beta - 1.0.0.86 - Text to SQL

 Free PlyxSQL© Beta - 1.0.0.86  - Text to SQL

POSTED BY GIULIANO PAGNINI, 30 LUG 2026

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

Dai dati grezzi alle risposte in una frase: la nuova interfaccia del nostro Assistente SQL

Chi lavora ogni giorno con i dati conosce bene il problema: le informazioni ci sono, sono nel database, ma tirarle fuori richiede una query SQL scritta a mano, spesso con l'aiuto di chi conosce lo schema a memoria. Abbiamo affrontato questo problema costruendo un assistente che parla la lingua di chi lo usa, non quella del database — e nell'ultimo aggiornamento abbiamo aggiunto tre funzionalità che lo rendono, semplicemente, più comodo da usare tutti i giorni.

Fai la domanda, non scrivere la query

Il punto di partenza resta lo stesso: si scrive una domanda in italiano — "quali utenti sono in mora?", "quanto ancora dobbiamo incassare del CUP nel 2026 diviso per le componenti ICP e TOSAP" — e l'assistente genera la query SQL, la esegue e mostra il risultato. 

Il risultato appare come tabella o, quando ha senso, come grafico (barre, linee, torta, dispersione) scelto in base alla forma dei dati: due colonne con una categoria e un numero propongono un grafico a barre, un solo numero secco diventa un gadget in evidenza, non una tabella da una cella.

Novità: una frase riassume il risultato prima ancora di leggerlo

La domanda più naturale, dopo aver ottenuto una tabella di trenta righe, è: "ok, ma in sintesi cosa significa?". Ora non serve più fare la somma a mente: sopra ogni risultato compare una riga con l'icona 💡 che riassume l'essenziale in una frase — quante righe, il totale, la media, e quale categoria pesa di più (con la percentuale sul totale).

Un dettaglio tecnico che ci teniamo a sottolineare: questa sintesi non è generata da un'intelligenza artificiale, è calcolata con la normale aritmetica sui dati che il risultato già contiene. Significa che è corretta per costruzione — niente numeri "plausibili ma sbagliati", il rischio tipico quando si chiede a un modello linguistico di fare i conti al posto tuo.

Novità: una dashboard che si aggiorna e si riordina

Ogni risultato interessante si può "pinnare" a una dashboard personale, per tenerlo a portata di mano insieme ad altre metriche — separata dalla chat, che invece resta pensata per l'esplorazione del momento.

Due funzionalità rendevano la dashboard un po' rigida, e ora non lo è più:

• Trascina per riordinare. I widget si spostano semplicemente trascinandoli con il mouse, per mettere in cima ciò che conta di più in questo momento. L'ordine resta salvato, non si perde ricaricando la pagina.
• Aggiorna con un clic. Un pulsante 🔄 su ogni widget rilancia la stessa domanda originale e sostituisce i dati con quelli freschi — utile per metriche che cambiano nel tempo, senza dover tornare in chat a riscrivere la domanda. C'è anche un "Aggiorna tutti" per rinfrescare l'intera dashboard in un colpo solo. E se un aggiornamento fallisce (rete assente, server temporaneamente giù), il widget non si svuota: resta l'ultimo dato buono, con un avviso discreto invece di un errore che cancella tutto.
• 
  
• 
  
  

Perché ce ne siamo occupati

Non sono funzionalità vistose, ma sono quelle che si notano quando mancano: una dashboard che non si riordina è una dashboard che si usa una volta e poi si ignora; un widget che va aggiornato ricreandolo da zero è un widget che smette di valere la pena. L'obiettivo, con questo aggiornamento, era semplice: rendere lo strumento qualcosa che si tiene aperto tutto il giorno, non solo qualcosa che si consulta una volta ogni tanto.

Il prossimo passo, già in cantiere, è una narrazione ancora più naturale generata da un modello linguistico — ma con una regola precisa: il modello racconterà i numeri, non li calcolerà mai da solo. La sintesi di oggi, quella aritmetica e verificabile, resterà comunque disponibile come base affidabile su cui costruire.

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

Free PlyxSQL© SQL Beta - 1.0.0.85 - Text to SQL

Free PlyxSQL© Beta - 1.0.0.85  - Text to SQL

POSTED BY GIULIANO PAGNINI, 28 LUG 2026

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

Dal Designer al browser: un vero chatbot text-to-SQL

Lo Schema Designer, il Configuratore Semantico, la finestra "Genera prompt AI" con la sua esecuzione di verifica e la sua autocorrezione. Il passo successivo renderlo disponibile a tutti sul web.

La risposta è un web server scritto in C++Builder (WebBroker su Indy) che espone lo stesso motore — prompt semantico, esecuzione, sicurezza, autocorrezione — come una manciata di endpoint HTTP, più un client Vue che li consuma. Non è stata una riscrittura da zero: è stato il momento in cui tutto il lavoro fatto sul lato "server" del Configuratore Semantico (pensato fin dall'inizio per essere indipendente dall'interfaccia desktop) ha dimostrato di reggere davvero fuori da quel contesto.

Server C++Builder (service o stand-alone GUI Application)

Il cuore: stesso motore, architettura diversa

SDServerPromptBuilder — il componente che trasforma una domanda in un prompt strutturato per l'AI — non ha richiesto una sola riga di modifica per girare sul web server. Era già stato progettato per non dipendere da nulla di specifico del Designer: solo RTL, nessuna dipendenza da componenti visuali. La differenza vera è stata nel come orchestrarlo.

Nel Designer, tutto girava sull'interfaccia utente: bisognava restare asincroni per non bloccare la finestra mentre si aspettava una risposta AI. Su un web server, ogni richiesta HTTP ha già il proprio thread — bloccarlo per la durata di una chiamata è normale, atteso, persino più semplice da scrivere. Lo stesso ciclo (prompt → AI → controllo di sicurezza → esecuzione → eventuale correzione) è diventato un semplice ciclo sincrono, senza bisogno dell'architettura a callback che serviva sul desktop.

Nessuno sconto sulla sicurezza

Il guardrail costruito per il Designer — solo SELECT di sola lettura, niente scritture, niente statement multipli — è arrivato intatto sul server. Ha senso: se qualcosa deve essere rigoroso, è proprio il confine tra "un chatbot può proporre una query" e "un chatbot può eseguire qualcosa contro un database di produzione". Ogni query, prima di toccare il database, passa dallo stesso controllo testuale rigoroso — e se anche l'AI dovesse inventarsi qualcosa di strano, il controllo non fa eccezioni per nessuno.

Il ciclo di autocorrezione ha guadagnato per strada un affinamento non banale: se un errore di esecuzione si ripete identico dopo che l'AI ha già prodotto una query diversa, il sistema smette di insistere. È nato da un caso reale — un errore di configurazione del database (non della query) che veniva rimandato all'AI tre volte di fila, sprecando ogni tentativo su qualcosa che nessuna riscrittura del SQL avrebbe mai potuto risolvere. Ora quel pattern viene riconosciuto e segnalato subito come probabile problema di infrastruttura, non di query.

Vedere cosa sta succedendo, non solo aspettare

Qui è dove le cose si sono fatte interessanti. Le prime versioni rispondevano in un unico blocco: silenzio totale, poi tutto insieme. Con un modello locale (Ollama) che può metterci anche un minuto a rispondere, quel silenzio è indistinguibile da un sistema bloccato.

La soluzione è stata disaccoppiare l'avvio dall'attesa: il client avvia il lavoro (che gira su un thread in background), riceve subito un identificativo, e interroga a ripetizione lo stato — un pattern di polling piuttosto che una singola chiamata bloccante. Da lì è nato un ticker che scandisce i secondi in tempo reale, e poi qualcosa di più preciso: passando alla modalità streaming di Ollama, il primo pezzo di testo che arriva diventa il confine naturale tra "il modello si sta ancora caricando/elaborando" e "sta generando davvero" — una distinzione che con una singola risposta bloccante non era osservabile in nessun modo. Il risultato: tre fasi visibili in tempo reale nel client, ognuna basata su un segnale vero, mai un'etichetta inventata.

Una cache che impara da sola

Sul Designer, la cache si alimentava da un gesto esplicito dell'operatore: un bottone "Verifica e salva come esempio". Sul server quel passaggio manuale è sparito del tutto — ogni volta che una domanda va a buon fine, la coppia domanda/query viene registrata automaticamente, perché un successo sul server è già una verifica reale contro il database. Nessuno deve ricordarsi di salvare nulla.

Stesse due soglie di sicurezza già validate sul Designer: corrispondenza esatta prima, corrispondenza approssimata solo sopra una soglia molto alta, e — il dettaglio a cui teniamo di più — mai un match se i numeri nelle due domande non coincidono. "Fatture 2024" e "fatture 2023" restano sempre due domande diverse, per quanto si somiglino nel resto della frase. E prima di restituire una risposta dalla cache come definitiva, il sistema la riesegue comunque per conferma: se lo schema o i dati sono cambiati nel frattempo, se ne accorge da solo e chiede una risposta fresca invece di rischiare.

Un file per portarsi via il risultato

Client Vue.js con Vuelityx

La tabella mostrata in chat è volutamente un'anteprima limitata (configurabile, 10 righe di default) — serve a confermare che la query funzioni, non a sostituire un vero export. Per quello c'è un endpoint dedicato che riesegue la stessa query, già passata dal controllo di sicurezza, con un tetto molto più alto, e restituisce un CSV vero e proprio, scaricabile con un click. Un dettaglio che conta più di quanto sembri: punto e virgola come separatore, non virgola — perché Excel in locale italiano usa la virgola come separatore decimale, e con il separatore sbagliato il file si aprirebbe tutto incolonnato in un'unica cella.

Sapere cosa sta succedendo, in aggregato

Ogni domanda che arriva a un esito — riuscita, fallita, risolta dalla cache — viene registrata in modo silenzioso: quanti tentativi sono serviti, quanto ci ha messo, se è arrivata dalla cache o dall'AI. Un endpoint restituisce il quadro aggregato: percentuale di successo, tempo medio, gli errori più frequenti. È il dato che dice dove guardare quando qualcosa non va, invece di doverlo dedurre osservando il client in tempo reale — è così, tra l'altro, che abbiamo diagnosticato un problema di configurazione FireDAC che altrimenti sarebbe sembrato un errore casuale dell'AI.

Il client: niente di più di quanto serva

Dall'altra parte, un frontend Vue essenziale — bolle di conversazione, evidenziazione del testo generato, una tabella per i risultati, un link per il CSV completo. Niente framework pesanti, niente stato complesso: solo quello che serve per rendere leggibile ciò che il server produce, con un dettaglio di attenzione che vale la pena raccontare — durante lo sviluppo, un bug di reattività (Vue 3 non sempre traccia le mutazioni su un oggetto se non è stato reso "reattivo" fin dall'inizio) faceva sì che l'interfaccia restasse bloccata sui primi tre puntini per sempre, qualunque cosa succedesse davvero lato server. Un promemoria utile: anche l'interfaccia più semplice ha i suoi dettagli sottili, e vale la pena controllarli con la stessa cura riservata al motore che sta dietro.

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

Free PlyxSQL© SQL Beta - 1.0.0.84 - Text to SQL

Free PlyxSQL© Beta - 1.0.0.84  - Text to SQL

POSTED BY GIULIANO PAGNINI, 27 LUG 2026

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

Da "genera una query" a "fidati del risultato": l'ultimo giro di lavoro sul motore text-to-SQL

Qualche settimana fa avevamo raccontato come il Configuratore Semantico avesse chiuso sei falle silenziose nel motore che traduce domande in linguaggio naturale in query SQL. Quel lavoro rispondeva a una domanda: l'AI ha capito bene lo schema del database? Ma c'era una domanda più scomoda che restava aperta: e se avesse capito bene la domanda, ma sbagliato comunque la query? E se qualcuno ponesse una domanda che, con la formulazione giusta, potesse far scrivere all'AI qualcosa di pericoloso?

L'ultimo giro di lavoro parte esattamente da lì. Non abbiamo aggiunto un modello più potente o un prompt più lungo — abbiamo aggiunto quello che mancava perché il sistema potesse fidarsi delle proprie risposte, invece di limitarsi a produrle.

Il cambio più importante: eseguire, non solo generare

Fino a poco fa, il flusso era: domanda in ingresso, SQL in uscita, testo mostrato a schermo. Nessuno controllava se quel SQL fosse davvero valido, se le colonne esistessero per davvero, se ci fosse un errore di sintassi nascosto in una condizione complicata. Il primo a scoprirlo era l'utente, alla peggio in produzione.

Ora la query generata viene eseguita davvero contro il database — con un tetto di righe restituite, giusto per validare, non per produrre un report — prima di essere mostrata come definitiva. E se fallisce? Qui sta il pezzo più soddisfacente di tutto il lavoro: l'errore vero restituito dal database viene rimandato all'AI, che tenta una correzione. Fino a tre tentativi, poi ci si ferma e si mostra l'ultimo errore senza fingere che vada tutto bene. Un nome di colonna scritto in modo leggermente sbagliato, un tipo di dato incompatibile — la maggior parte di questi errori si risolve da sola al secondo tentativo, con il messaggio d'errore giusto in mano.

Accanto a questo, un guardrail di sicurezza che non fa sconti: solo SELECT di sola lettura. Niente DROP, DELETE, UPDATE, niente più di uno statement nella stessa risposta. Non è un controllo "quasi sicuro" — è deliberatamente severo, con la filosofia che in caso di dubbio si rifiuta, anche a costo di qualche falso positivo su una query insolita ma legittima.

E per chi vuole verificare una query ottenuta fuori dal programma — magari incollando il prompt in un altro strumento e portando indietro il risultato — c'è ora un bottone "Testa SQL" che applica esattamente gli stessi controlli, senza passare dall'AI.

Una cache che non si fida ciecamente di se stessa

Ogni domanda, anche identica a una già fatta, richiamava l'AI da zero. Ora no: le domande verificate con successo (tramite il nuovo bottone "Verifica e salva come esempio") diventano candidate per una cache a due livelli — corrispondenza esatta, e corrispondenza approssimata con una soglia alta.

Il dettaglio a cui teniamo di più: la cache non si fida ciecamente di se stessa. Prima di restituire una risposta cache-hit come definitiva, la ri-esegue per conferma. E se la configurazione semantica della tabella coinvolta è cambiata da quando l'esempio è stato verificato, se ne accorge da sola e chiede una risposta fresca invece di rischiare. Anche il rischio più insidioso di una cache testuale — confondere "fatture 2024" con "fatture 2023" solo perché le due frasi si somigliano — è gestito esplicitamente: un controllo separato confronta i numeri delle due domande, e se non coincidono il match viene scartato, qualunque sia la somiglianza del resto della frase.

Domande che si ricordano di quella prima

Un piccolo tassello, ma che cambia parecchio l'esperienza d'uso: ora è possibile spuntare "mantieni il contesto della domanda precedente", e una domanda come "e nel 2025?" dopo "utenti in mora nel 2024" viene interpretata correttamente come una variazione, non come una domanda a sé stante e incomprensibile. La decisione se collegare le due domande resta sempre dell'AI, in base al testo reale — nessun collegamento forzato quando non ha senso.

Sapere dove investire tempo, senza doverlo indovinare

Fino a ieri, l'unico modo per sapere se la configurazione funzionava bene era testarla a mano. Ora ogni domanda posta realmente in produzione viene registrata in modo silenzioso — sorgente (cache o AI), tabelle coinvolte, esito. Una finestra dedicata mostra il quadro aggregato: percentuale di richieste risolte dalla cache, tasso di successo, tabelle ed errori più frequenti. È il dato che dice dove mettere le mani la prossima volta, invece di doverlo indovinare guardando i log a occhio.

Chi può vedere cosa

L'ultima aggiunta strutturale: permessi per ruolo su tabelle e singoli campi. Un ruolo può non vedere l'esistenza stessa di una tabella riservata, o vedere una tabella ma non uno dei suoi campi. La parte importante, quella su cui abbiamo insistito di più: il controllo vero vive solo nel componente server, quello che riceve un ruolo già autenticato da chi lo interpella — non nel Designer, dove esiste solo un'anteprima etichettata chiaramente come tale, utile per verificare la configurazione ma mai spacciata per un confine di sicurezza reale.

Le rifiniture che si notano solo quando mancano

Un po' di lavoro è andato anche in cose meno appariscenti ma che si sentono nell'uso quotidiano:

• Le celle che prima accettavano testo libero per cardinalità, tipo di join, o valore di un parametro dinamico ora offrono tendine a scelta vincolata — impossibile scrivere un valore che il sistema non riconoscerebbe.
• Le espressioni SQL lunghe, nei popup di modifica, vengono ora formattate ed evidenziate automaticamente, con un bottone per riformattare su richiesta — niente più muri di testo su una riga sola.
• Un controllo al salvataggio avvisa se un filtro condizionale rischia di non attivarsi mai, perché le sue parole chiave non compaiono da nessuna parte tra quelle che decidono se includere la tabella nel prompt.
• Una Suite di Regressione riesegue automaticamente gli esempi noti, per accorgersi subito se una modifica alla configurazione ha rotto qualcosa che prima funzionava.

Il filo conduttore, di nuovo

Lo stesso di sempre, solo applicato a un pezzo diverso del problema: un sistema affidabile non nasce da un salto tecnologico, nasce da mille decisioni su cosa fare quando qualcosa va storto. Eseguire prima di mostrare. Rifiutare prima di rischiare. Ricontrollare prima di fidarsi della cache. Avvisare prima di lasciare che un problema resti invisibile fino a quando qualcuno lo scopre nel modo peggiore.

Non è il genere di lavoro che finisce in una demo entusiasmante. È il genere di lavoro che decide se, tra sei mesi, qualcuno userà ancora questo strumento — o avrà smesso dopo la prima risposta sbagliata di cui nessuno si è accorto.

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

Free PlyxSQL© SQL Beta - 1.0.0.81 - Text to SQL

 Free PlyxSQL© Beta - 1.0.0.81  - Text to SQL

POSTED BY GIULIANO PAGNINI, 23 LUG 2026

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

1. Few-shot examples: mostrare invece di spiegare

Per ogni tabella si può ora configurare un piccolo set di coppie domanda → SQL già validate da un operatore umano. Non sono documentazione: finiscono letteralmente nel prompt come esempi di riferimento.

È il tipo di intervento che nella letteratura sul text-to-SQL ha il rapporto costo/beneficio più alto: una descrizione testuale di un JOIN complesso o di una CASE particolare lascia sempre margine di interpretazione, un esempio concreto no. E quando la domanda dell'utente somiglia a un esempio già validato, il modello smette di "indovinare" lo stile giusto e inizia a copiarlo.

2. Filtri incondizionati: la differenza tra "se serve" e "sempre"

Il configuratore aveva già i Keyword Filter: un filtro WHERE che scatta se una parola specifica compare nella domanda. Utile, ma con un buco di sicurezza evidente — se l'operatore non usa la parola giusta, il filtro semplicemente non scatta. Un record cancellato può finire in una query senza che nessuno l'abbia chiesto.

Gli always_filters risolvono esattamente questo: espressioni WHERE che vengono applicate sempre quando la tabella è coinvolta, indipendentemente da cosa scrive l'utente. Non sono un'opzione tra le tante nel prompt — arrivano accompagnate da un'istruzione esplicita che dice al modello: questo non è negoziabile, non è un'ipotesi, va sempre in AND. Soft delete, isolamento multi-tenant, esclusione di record di sistema: tutto ciò che deve valere a prescindere ora ha un posto dove stare.

3. Il formato che invecchia bene

Ogni volta che un formato di scambio dati vive abbastanza a lungo, arriva il giorno in cui cambia. Il pacchetto semantico esportato per il componente server ora porta un format_version come primo campo. Non è burocrazia: è la differenza tra un server che sa di dover ignorare educatamente un campo che non conosce ancora, e un server che lo interpreta male senza accorgersene. Non abbiamo aggiunto un blocco rigido — solo un avviso, mai un errore: forward-compatibility onesta, non difensiva all'eccesso.

4. Quando la domanda nomina due cose, non una

Questo è il bug più subdolo che abbiamo trovato. Il sistema aveva un meccanismo per mappare, ad esempio, il nome di un comune al suo codice interno — ma restituiva sempre un valore, quello di default. Se la domanda dell'utente diceva "confronta le occupazioni suolo tra Riccione e Gatteo", il sistema silenziosamente ignorava Gatteo e rispondeva solo per Riccione. Nessun errore, nessun avviso — solo una risposta a metà, spacciata per completa.

Ora ogni valore configurato porta un flag matched calcolato contro il testo reale della domanda, e quando più varianti dello stesso parametro risultano nominate esplicitamente, il prompt le espone tutte insieme in una sezione dedicata — con un'istruzione che vieta esplicitamente al modello di sceglierne una sola. Da lì il modello costruisce un IN (...) o l'unione che serve. La differenza tra "sembra funzionare" e "funziona davvero" spesso sta proprio in questo genere di casi limite.

5. Cosa succede quando lo schema ha 300 tabelle

Un prompt che include "tutte le tabelle perché non abbiamo capito quale serve" è già una toppa accettabile su uno schema piccolo. Su uno schema con centinaia di tabelle configurate diventa un problema serio: costo in token, e soprattutto rumore che confonde il modello più di quanto lo aiuti.

Abbiamo introdotto una soglia oltre la quale il sistema non include più tutto, ma ordina le tabelle candidate per un punteggio di pertinenza (il nome tabella nella domanda pesa più di una singola keyword) e tiene solo le migliori. Sempre con un avviso esplicito su quante e perché sono state escluse — mai un troncamento silenzioso che l'utente scopre solo quando manca qualcosa.

6. Quando "occupazione" nella configurazione non trova "occupazioni" nella domanda

L'ultimo pezzo è forse quello con il ritorno più immediato sulla qualità percepita. Il motore di riconoscimento delle tabelle cercava corrispondenze esatte, parola per parola. Se una keyword era configurata al singolare e l'utente scriveva al plurale, semplicemente non scattava — e il sistema, non trovando nulla, finiva dritto nel fallback "includi tutto".

Ora, solo dopo che il match esatto ha fallito, entra in gioco un secondo tentativo più permissivo: confronto per distanza di edit tra le parole, capace di riconoscere plurali, generi, piccoli refusi. Non è magia — non copre sinonimi concettualmente diversi, quello richiederebbe tutt'altro tipo di motore — ma chiude una fetta enorme dei "non ho capito la domanda" più frustranti, quelli dove la domanda era in realtà perfettamente chiara a un essere umano.

Un dettaglio non banale: questo fallback approssimato vale solo per decidere quali tabelle mostrare come contesto. Non tocca mai i filtri o i valori che finiscono letteralmente nel SQL generato — lì un match "quasi giusto" cambierebbe il risultato della query, non solo il contesto, ed è un rischio che semplicemente non vale il beneficio.

Il filo conduttore

Se c'è una lezione in tutto questo, è che un sistema text-to-SQL affidabile non nasce da un prompt più lungo o da un modello più potente. Nasce da mille piccoli casi limite trattati uno per uno, ciascuno con la stessa domanda di fondo: cosa succede davvero quando l'utente scrive qualcosa che non avevo previsto? A volte la risposta è "fallisci in modo rumoroso, con un avviso chiaro". Altre volte è "prova un secondo approccio, più permissivo, ma dillo". Non è mai "fai finta che vada tutto bene".

È un lavoro meno appariscente di un nuovo modello o di un prompt più elaborato. Ma è quello che, alla fine, decide se un utente si fida del sistema oppure smette di usarlo dopo la prima risposta sbagliata.

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

Free PlyxSQL© SQL Beta - 1.0.0.79 - Text to SQL

Free PlyxSQL© Beta - 1.0.0.79  - Text to SQL

POSTED BY GIULIANO PAGNINI, 20 LUG 2026

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

Il Configuratore Semantico plyxSQL: dalla mappatura dei campi a una vera base di conoscenza

Il Configuratore Semantico di plyxSQL Schema Designer è nato come un ponte tra lo schema fisico di un database e un modello linguistico chiamato a generare SQL a partire da domande in linguaggio naturale. Nelle ultime settimane si è arricchito di una serie di funzionalità pensate per un solo obiettivo: dare all'AI più contesto, riducendo al minimo gli errori di interpretazione — join sbagliati, campi inventati, valori "congelati" nel tempo.

Ecco cosa è cambiato.

1. Relazioni esplicite tra le tabelle

Fino a poco tempo fa, un lookup diceva solo "questo campo punta a quest'altra tabella" — ma non diceva come. Un JOIN su una relazione uno-a-molti può duplicare righe silenziosamente se non gestito con un GROUP BY; scegliere INNER invece di LEFT può far sparire dai risultati proprio i record che l'utente voleva vedere.

Ogni lookup ora può portare con sé due informazioni in più:

• Cardinalità — 1:1, 1:N o N:1
• Tipo di JOIN — INNER, LEFT o RIGHT

Quando importi un lookup direttamente da una foreign key reale dello schema, il Designer propone già un valore sensato: N:1 come cardinalità tipica, e LEFT se il campo di riferimento è opzionale (nullable) — così un record senza quel collegamento non sparisce dai risultati per un dettaglio tecnico che l'utente non ha motivo di conoscere.

2. Chi rappresenta una riga? Il campo "identificatore umano"

Una domanda come "mostrami gli utenti" richiede all'AI di scegliere quale campo elencare — l'ID numerico non serve a nessuno. Ora un campo per tabella può essere marcato come identificatore umano (tipicamente una ragione sociale, un nome, una descrizione): quando la domanda non specifica quali colonne vuole, l'AI sa già cosa mostrare accanto alla chiave primaria, senza dover indovinare.

3. Cosa rappresenta davvero questa tabella?

I nomi fisici delle tabelle non sono sempre parlanti. SBEREGPERM non dice granché a un modello linguistico, per quanto bravo sia a indovinare gli acronimi. Ogni tabella può ora avere una descrizione libera — poche parole di contesto ("registrazioni permanenti") distinte dalle keyword di rilevamento, che restano espressioni booleane pensate per un altro scopo: decidere quando includere la tabella, non spiegarne il significato.

4. Una mappa per vedere lo schema semantico, non solo quello fisico

Configurare dieci, venti tabelle con keyword, lookup, filtri e campi calcolati produce, nel tempo, una configurazione che nessuno tiene più a mente per intero. Il Designer offre ora una vista dedicata — un grafico separato dallo schema fisico, raggiungibile con un bottone in sidebar — che mostra solo le tabelle effettivamente configurate, ciascuna con il proprio alias, la keyword principale e due contatori rapidi (filtri e campi calcolati configurati). Le relazioni tra tabelle appaiono come curve etichettate con cardinalità e tipo di join; passando il mouse su un nodo si vede il dettaglio completo — keyword intere, filtri con la loro espressione, lookup, tutto quello che il riquadro compatto non può mostrare senza affollare la vista.

Non è un doppione dello schema fisico: è la rappresentazione di quello che l'AI vede davvero quando genera una query.

5. Custom key che non invecchiano: le macro temporali

Molte configurazioni usano parametri come [[ANNO]] per puntare a tabelle organizzate per anno (SBEREGISTRO2026, e l'anno prossimo SBEREGISTRO2027). Fino a poco fa, il valore di quel parametro andava aggiornato a mano, una volta l'anno, da qualcuno che se lo ricordasse.

Ora il campo "Valore" di una custom key può contenere un'espressione dinamica — YEAR(TODAY()), CURRENT_DATE, YEAR(TODAY())-1 per l'anno precedente, e altre dodici — che viene risolta al valore vero nel momento in cui viene generata una domanda reale, non quando la configurazione viene salvata o esportata. Una combo dedicata, in fondo alla finestra di configurazione globale, elenca tutte le espressioni riconosciute: si seleziona la riga della tabella, si sceglie l'espressione dalla combo, ed è fatto.

Il punto tecnico interessante è quando avviene questa risoluzione — ed è anche il punto più facile da sbagliare, se non ci si pensa fin dall'inizio.

La scelta di risolvere l'espressione al momento della richiesta, e non prima, è quella che fa funzionare tutto il resto: il pacchetto configurato oggi resta corretto anche tra un anno, senza che nessuno debba ricordarsi di aggiornarlo — è il processore delle macro, non la configurazione, a occuparsi di restare aggiornato.

In sintesi

Nessuna di queste funzionalità, da sola, cambia radicalmente il configuratore. Messe insieme, spostano l'ago della bilancia da "un dizionario di mapping tra parole e colonne" verso qualcosa che si avvicina a una vera base di conoscenza: relazioni con un verso e una molteplicità precisi, tabelle che sanno spiegare cosa sono, valori che restano corretti senza manutenzione, e una mappa per vedere tutto questo a colpo d'occhio invece di ricostruirlo a memoria ogni volta.

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