lunedì 26 ottobre 2026

Free VueLityx© Il builder visuale per Vue.js, Vite e Nuxt prossimo al rilascio

Free VueLityx© Il builder visuale per Vue.js, Vite e Nuxt

POSTED BY GIULIANO PAGNINI, 26 OTT 2026

Da quando ho iniziato VueLityX l'obiettivo è uno solo: fare per Vue.js quello che Delphi ha fatto per Windows. Un ambiente RAD vero, dove disegni l'interfaccia, colleghi i dati e gli eventi, provi e correggi, senza perdere mai il controllo del codice. Nelle ultime settimane sono arrivate alcune delle funzioni che più avvicinano VueLityX a quell'idea: ecco cosa c'è di nuovo.

In breve

Debugger sull'anteprima, con breakpoint, passo a passo e variabili
Breakpoint direttamente nell'editor, con un clic sul margine
Language server Vue (Volar) nell'editor: errori veri, completamento con i tipi, rinomina su tutto il progetto
Align e Anchors come in Delphi, per i componenti Vue
Object Repository: componenti e viste riutilizzabili tra progetti
Esplora database e dati a design time
Interfaccia in 9 lingue
FormCapacitorBuilder: dal progetto Vue all'app Android (APK e AAB) con Capacitor

1. Un debugger come quello di Delphi, sull'anteprima

Il menu Debug apre un debugger che lavora direttamente sull'anteprima dell'app, senza DevTools esterni. Si mettono i breakpoint sulle righe dei file .vue e .js del progetto e, quando il codice ci passa, l'esecuzione si ferma.

Comandi di Delphi: Continua (F9), Passo (F8), Entra (F7), Esci (Maiusc+F8).
Stack delle chiamate e variabili espandibili: locali, di chiusura, di blocco e del modulo, con i ref mostrati per il loro valore.
Valuta / Modifica: scrivi un'espressione (conta.value, conta.value = 5) e vedi subito il risultato.
Le righe sono quelle del tuo file: grazie alle source map di Vite, il breakpoint messo alla riga 31 di Home.vue si ferma proprio lì, non nel codice generato.
Anche il codice di avvio: "Ricarica pagina" riparte dall'inizio, così ci si ferma anche nello <script setup> e nel primo disegno del template.
Le librerie si saltano (node_modules, client di Vite) e si sceglie se fermarsi sulle eccezioni.

2. Breakpoint nell'editor, con un clic

Come in Delphi, il breakpoint si mette cliccando sul margine a sinistra dei numeri di riga, oppure con F5 sulla riga del cursore. Compare il pallino rosso; un altro clic lo toglie.

Funziona anche a debugger chiuso: quando lo apri, i breakpoint sono già lì.
Se aggiungi o togli righe sopra, il pallino segue il codice.
Quando il debugger si ferma, la riga in esecuzione è evidenziata in giallo nell'editor.
Aprendo il debugger, mostra già il file dell'editor alla riga del cursore.

3. L'editor ora "capisce" Vue: arriva il language server

L'editor di codice di VueLityX è basato su Monaco, lo stesso motore di Visual Studio Code. Adesso è collegato anche al language server ufficiale di Vue (Volar), quello che usa VS Code: l'editor non si limita più a colorare il testo, conosce davvero il progetto.

Errori TypeScript e Vue mentre scrivi, nella lingua dell'IDE: "Il tipo 'string' non è assegnabile al tipo 'number'".
Completamento con i tipi: scrivendo <Hello l'editor propone le props del componente figlio.
Import automatici: scegli computed dall'elenco e l'import da vue si aggiunge da solo.
Tipo al passaggio del mouse e firma dei parametri quando apri la parentesi di una funzione.
Vai alla definizione (F12 o Ctrl+clic), anche in un altro file, che si apre alla riga giusta; Alt+F12 per l'anteprima al volo.
Rinomina su tutto il progetto (F2): rinomini una funzione in App.vue e cambia anche in utils.ts.
Formatta documento, mantenendo gli a-capo del file.

Il language server gira in un piccolo processo Node.js che VueLityX avvia da solo in background (la prima volta installa i pacchetti necessari) e chiude insieme all'IDE. Un pallino "Vue" in basso a destra nell'editor ne mostra lo stato.

4. Align e Anchors, come in Delphi

Chi viene da Delphi conosce bene Align := alClient e Anchors := [akRight, akBottom]. Ora esistono anche per i componenti Vue, come direttive sul tag, e si impostano dall'Object Inspector:

<header v-align="'top'">...</header>
<aside  v-align="'left'">...</aside>
<main   v-align="'client'">...</main>      <!-- riempie lo spazio che resta -->
<button v-anchors="'right,bottom'">OK</button>

Dietro c'è CSS moderno (griglia e flex), applicato solo come stile in linea: nessun CSS globale, e togliendo la direttiva l'elemento torna com'era. Funziona con Vite e con Nuxt.

5. Object Repository

L'equivalente di File > New > Other... e Add to Repository di Delphi. Un componente o una vista riuscita si salva nel Repository e si riusa in qualunque progetto, con i suoi file e le dipendenze che richiede.

Elementi di serie già pronti: barra di stato, finestra di dialogo, pagina con layout, scheda di accesso.
Elementi personali, salvati nella propria cartella utente.
Nomi e descrizioni nelle lingue dell'IDE.

6. Esplora database e dati a design time

Esplora database (il Data Explorer di Delphi) si collega al database del backend con FireDAC e mostra tabelle, campi con tipo e chiave, e un'anteprima dei dati. Con un clic, "Crea datasource dalla tabella" aggiunge al DataModule un datasource REST già pronto verso l'API di quella tabella, anche con chiavi composte.

Con i dati a design time l'anteprima si vede piena anche mentre la disegni: dalla combo "Dati" scegli fra dati reali, dati di esempio o datasource spenti. Le griglie mostrano un badge che dice da dove arrivano i dati, così non si confonde mai l'esempio con il vero.

7. Sempre più Delphi: eventi, azioni, struttura

Scheda Eventi nell'Object Inspector: assegni un gestore scegliendo fra le funzioni dello <script setup> o creandone uno nuovo, e lo rinomini o lo scolleghi.
ActionList: le azioni del progetto (testo, suggerimento, scorciatoia, abilitazione) in un editor dedicato, e "Collega azione..." mette v-action sul componente.
Structure View: l'albero dei componenti, dove si spostano gli elementi trascinandoli e si rilasciano nuovi componenti dalla galleria.
Crea componente da qui: un pezzo di template diventa un componente nuovo, già importato.
Annulla / Ripeti di tutte le modifiche fatte dal designer, e il pannello Problemi che porta al file e alla riga dell'errore.

8. VueLityX parla 9 lingue

L'interfaccia è disponibile in italiano, inglese, tedesco, francese, spagnolo, portoghese, russo, cinese e giapponese, compresi i nuovi strumenti: debugger, repository, esplora database e i messaggi del language server. La lingua si cambia dal menu, senza riavviare.

9. Dalla web app all'app Android: FormCapacitorBuilder

Con Build Capacitor... un progetto Vue + Vite diventa un'app Android nativa grazie a Capacitor, pronta da installare sul telefono o da pubblicare sul Play Store. Lo stesso codice che gira nel browser, senza riscrivere nulla. La finestra si apre già sulla cartella del progetto attivo: si compilano pochi campi e si preme Build.

Cosa si imposta

Nome dell'app, nome breve, descrizione, versione e codice di versione.
ID dell'app (es. it.miaazienda.miaapp), proposto in automatico dal nome breve e controllato nel formato.
Icona: un PNG (consigliato 1024×1024) da cui si generano tutte le icone Android, con anteprima.
Orientamento: automatico, verticale o orizzontale.
URL del backend: l'indirizzo del server che l'app userà per le API.
Tipo di output: APK di debug, APK release o AAB per il Play Store, con keystore, alias e password per la firma.
Opzioni per lo sviluppo: traffico HTTP non cifrato (per i server di prova) e debug della WebView da Chrome.

La configurazione si salva nel progetto e si ritrova alla volta successiva. Le password invece non vengono mai salvate.

Cosa fa da solo, in 10 passi

Controlla l'ambiente: Java JDK 17 o superiore (anche quello incluso in Android Studio) e Android SDK, cercati nei posti abituali.
Installa Capacitor se manca (@capacitor/core, cli, android), allineando le versioni fra loro.
Genera capacitor.config.json. Se il progetto ha già un capacitor.config.ts o .js, lo rispetta e non lo tocca.
Aggiorna package.json (nome, versione, script cap:*) senza toccare gli script esistenti.
Adatta il codice web alla WebView: percorsi relativi in vite.config, Vue Router in modalità hash (così ricarica, link diretti e tasto Indietro funzionano sempre), e l'indirizzo delle API letto da VITE_API_BASE.
Build Vite con un .env.production che punta al backend remoto.
Aggiunge la piattaforma Android (solo la prima volta) e sincronizza Capacitor.
Genera le icone con @capacitor/assets.
Scrive nel progetto Android nome dell'app, ID, versione e orientamento.
Compila con Gradle e copia il risultato in dist-capacitor, con un nome chiaro come miaapp-1.0.0-release.aab.

Pensato per non fare danni

I file del progetto web modificati per la build vengono salvati prima e ripristinati alla chiusura: il progetto resta quello di sempre.
La build si può annullare in qualsiasi momento, e si fermano anche i processi figli (npm, Node, Gradle, Java). Durante la build la finestra non si chiude per sbaglio.
Se Gradle fallisce, il registro mostra le righe di errore e suggerisce la causa più probabile: licenze dell'SDK da accettare, JDK sbagliato, SDK non trovato. Il log completo finisce in capacitor-build.log.
Un pulsante apre il progetto in Android Studio (npx cap open android), per emulatore, debug nativo e plugin.

#Delphi #VueJS #CPPBuilder #LowCode #WebDevelopment #VueLityX

mercoledì 21 ottobre 2026

VueLityx© Il builder visuale per Vue.js, Vite e Nuxt

POSTED BY GIULIANO PAGNINI, 22 OTT 2026

Quante volte hai iniziato un nuovo progetto Vue e hai passato le prime ore… a configurare? Cartelle, dipendenze, import, componenti da collegare a mano.

E se potessi saltare tutto questo e passare subito alla parte che conta davvero: il tuo prodotto? Ti presento VueLityX, il builder visuale che Vue meritava. VueLityX è un ambiente RAD, Rapid Application Development, sviluppato da pgsoft.it per creare applicazioni Vue.js con Vite e Nuxt in modo rapido e professionale.

L’idea è semplice: meno configurazione, più prodotto. Costruisci le tue pagine in modo visuale, con il drag & drop. Scegli un componente, lo trascini dove ti serve e VueLityX fa il resto: inserisce il markup nel template, aggiunge l’import nello script setup e crea automaticamente i file del componente nel progetto. Ma non perdi mai il controllo del codice. Accanto alla parte visuale hai un editor integrato: tutto quello che VueLityX genera è codice Vue pulito, leggibile, che puoi modificare quando vuoi.

JavaScript o TypeScript? Scegli tu: il tool si adatta al tuo progetto. Ogni componente porta con sé le proprie dipendenze, e VueLityX le installa per te. Niente più pacchetti dimenticati o versioni da allineare a mano. Tutto è guidato da JSON: componenti, configurazioni, contenuti del sito. Una sola fonte di verità, facile da mantenere, versionare e riutilizzare tra un progetto e l’altro. E con l’integrazione dell’intelligenza artificiale, VueLityX ti aiuta a generare e rifinire componenti e pagine ancora più velocemente.Non è solo teoria. PackConfigurator, un configuratore 3D per l’ottimizzazione degli imballaggi, è stato sviluppato interamente con VueLityX, insieme al suo sito web in Nuxt.

Un’applicazione complessa, con grafica 3D e calcoli di ottimizzazione, costruita in una frazione del tempo abituale. VueLityX: per sviluppatori Vue che vogliono costruire di più, configurando di meno.

Scopri di più su vuelityx.com, iscriviti al canale e attiva la campanella per non perdere i prossimi tutorial.

https://vuelityx.com/

#Delphi #VueJS #CPPBuilder #LowCode #WebDevelopment #VueLityX

sabato 17 ottobre 2026

Free PlyxSQL© - 1.0.0.112

SQLManagerMenu: corretti bug nella gestione dei progetti e migliorata la robustezza del motore SQL

Introduzione

Lo sviluppo di SQLManagerMenu prosegue con un nuovo ciclo di manutenzione tecnica dedicato alla stabilità dell'applicazione, alla correttezza della gestione dei progetti e all'affidabilità dell'elaborazione degli script SQL.

L'obiettivo è rendere sempre più solida un'applicazione che integra gestione delle connessioni, navigazione degli oggetti database, generazione DDL, Query Builder ed editor SQL, con particolare attenzione alle differenze sintattiche tra i principali database relazionali.

Le ultime modifiche si sono concentrate sulla gestione dello stato del progetto, sulla tokenizzazione degli identificatori SQL e sul rafforzamento dei controlli durante l'elaborazione del DDL.

1. Corretta la gestione delle modifiche al progetto

Uno dei problemi individuati riguardava il comportamento del sistema durante il cambio della scheda attiva.

In precedenza, la semplice selezione di una scheda poteva determinare la marcatura del progetto come modificato, anche in assenza di modifiche effettive al contenuto.

Questo comportamento poteva generare richieste di salvataggio superflue e rendere meno chiara la distinzione tra navigazione nell'interfaccia e modifica dei dati.

La gestione è stata corretta per evitare che il solo cambio di scheda provochi automaticamente la marcatura del progetto come modificato.

È stato inoltre corretto l'handler responsabile della notifica delle modifiche, che in precedenza ignorava il parametro booleano ricevuto e impostava sempre lo stato di modifica.

Questi interventi costituiscono un passo importante verso una gestione più coerente dello stato del progetto.

2. Migliorata la tokenizzazione degli identificatori SQL

Un'altra area interessata dalle correzioni è il tokenizer utilizzato durante l'analisi degli script DDL.

I diversi database utilizzano convenzioni differenti per delimitare gli identificatori. Alcuni esempi sono:

Virgolette doppie per gli identificatori delimitati.
Backtick in MySQL e MariaDB.
Parentesi quadre in SQL Server.

All'interno degli identificatori possono inoltre comparire caratteri di escape che devono essere interpretati correttamente.

Il tokenizer è stato aggiornato per gestire meglio gli identificatori delimitati e le rispettive sequenze di escape, riducendo il rischio di suddivisioni errate dei token durante l'analisi del codice SQL.

Questa correzione è particolarmente importante quando si lavora con nomi di tabelle, colonne o altri oggetti che contengono caratteri speciali.

3. Migliorata la gestione degli input incompleti

La gestione degli script incompleti è un aspetto fondamentale per un parser DDL affidabile.

Un identificatore privo del delimitatore finale o una stringa non terminata possono indicare che il codice è stato troncato oppure che contiene un errore sintattico.

Il lavoro sul tokenizer ha introdotto controlli più rigorosi su queste situazioni, con l'obiettivo di evitare che input incompleti vengano interpretati come token validi.

La corretta gestione di questi casi contribuisce a rendere più prevedibili le fasi successive di parsing e generazione DDL.

4. Rafforzati i test del generatore DDL

La manutenzione ha interessato anche la suite di test del generatore DDL.

Sono stati aggiunti o ampliati test relativi a diversi casi limite, tra cui:

Identificatori contenenti caratteri di escape.
Stringhe e identificatori non terminati.
Regole di quoting specifiche di PostgreSQL.
Commenti annidati.
Rilevamento dei segnaposto negli script.

L'ampliamento dei test permette di documentare meglio il comportamento atteso dei componenti e costituisce una base più solida per le future modifiche.

La presenza di nuovi test, tuttavia, non equivale automaticamente alla certificazione del loro superamento: la suite deve essere eseguita e verificata nell'ambiente di compilazione previsto.

5. Migliorati i controlli sui segnaposto DDL

Gli script generati possono contenere segnaposto temporanei, come TODO, oppure sezioni incomplete che devono essere completate prima dell'esecuzione.

Il sistema dispone di controlli dedicati a questi casi, utilizzati anche nei percorsi di esecuzione degli script.

L'obiettivo è evitare che codice incompleto venga trattato come SQL pronto per essere eseguito.

Particolare attenzione è stata dedicata alla necessità di distinguere il testo effettivo del codice dai contenuti presenti nelle stringhe e nei commenti.

Questa area rimane oggetto di ulteriori verifiche per garantire una gestione coerente delle diverse convenzioni lessicali dei database supportati.

6. Attenzione alla compatibilità tra dialetti SQL

La gestione multi-dialetto rimane uno degli aspetti tecnici più importanti di SQLManagerMenu.

Un'istruzione valida su un database potrebbe non essere supportata da un altro, oppure potrebbe richiedere una versione minima specifica del server.

Per questo motivo, la generazione DDL deve tenere conto non soltanto del tipo di database, ma anche delle sue caratteristiche e della versione effettiva.

Tra gli aspetti che richiedono particolare attenzione rientrano:

La sintassi per creare o modificare procedure, funzioni e trigger.
Le regole di quoting degli identificatori.
I delimitatori utilizzati negli script composti.
Le differenze tra le versioni dei singoli DBMS.
Le proprietà dello schema che non possono essere rappresentate direttamente nel modello interno.

L'obiettivo è evitare che il generatore produca script apparentemente corretti ma incompatibili con il database di destinazione.

#SQL #database #ETL #DataEngineering #plyxSQL #FireDAC #PGSOFT

giovedì 8 ottobre 2026

Free PlyxSQL© - 1.0.0.111

PlyxSQL 111: il nuovo SQL Manager cross-database per sviluppatori professionisti

PlyxSQL v30 rappresenta una nuova importante evoluzione di un ambiente SQL progettato per lavorare con database differenti attraverso un'unica piattaforma.

La nuova versione introduce una revisione architetturale profonda che coinvolge gestione delle connessioni, SQL Builder, SQL Editor, Schema Designer, generazione DDL, capability SQL, versioni dei database e test di compatibilità.

L'obiettivo è ambizioso: offrire agli sviluppatori un ambiente nel quale la generazione SQL non dipenda semplicemente dal nome del database, ma dal contesto reale del server e dalle funzionalità effettivamente disponibili.

Un unico ambiente per database differenti

Uno dei problemi più complessi nello sviluppo di strumenti SQL multi-database è rappresentato dalle differenze tra i vari dialetti.

Una query valida su PostgreSQL potrebbe non essere valida su SQL Server.

Una sintassi disponibile su MySQL 8 potrebbe non essere disponibile su MySQL 5.7.

MariaDB e MySQL possono condividere molta sintassi, ma non sono sempre equivalenti.

DB2, Informix e Microsoft Access introducono inoltre numerose peculiarità specifiche.

PlyxSQL v30 affronta questo problema con una nuova architettura basata sul concetto di SQL Workspace.

SQL Workspace: il cuore della nuova architettura

Il nuovo TSQLWorkspaceContext raccoglie in un unico contesto tutte le informazioni necessarie alla gestione SQL.

Il Workspace comprende:

connessione;
dialetto SQL;
prodotto;
versione del server;
origine delle informazioni;
sessione SQL;
capability;
generazione del contesto.

Il vantaggio è importante: Builder, Editor, Designer e altre funzionalità possono lavorare sullo stesso contesto SQL.

L'architettura può essere rappresentata così:

Connessione
     │
     ▼
Tree Explorer
     │
     ▼
SQL Workspace Context
     │
 ┌───┼───────────────┐
 ▼   ▼               ▼
Builder Editor   Schema Designer
     │
     ▼
SQL / DDL

Questa struttura riduce drasticamente il rischio che componenti differenti utilizzino informazioni diverse sul database attivo.

Database, prodotto e versione: una distinzione fondamentale

PlyxSQLv30 introduce una gestione più precisa dell'identità del database.

Non viene considerato soltanto il semplice dialetto.

Il sistema distingue tra:

Dialect

Product

Server Version

Session

Capabilities

Questa distinzione è fondamentale per gestire correttamente database come MySQL e MariaDB.

MySQL e MariaDB finalmente distinti

MySQL e MariaDB condividono moltissima sintassi, ma non sono lo stesso prodotto.

La v30 introduce quindi una gestione esplicita del prodotto.

Questo permette al sistema di sapere che una connessione utilizza:

Dialect: MySQL
Product: MariaDB

quando questa è la rappresentazione sintattica più appropriata.

Il risultato è una base molto più solida per gestire le differenze specifiche dei due database.

AutoDetect più affidabile

La funzione di autodetection è stata migliorata per evitare che il rilevamento automatico sovrascriva arbitrariamente le impostazioni definite manualmente.

Il sistema può utilizzare informazioni provenienti da:

driver;
server;
progetto;
configurazione manuale.

La scelta manuale dell'utente viene quindi rispettata.

Questo rende il comportamento molto più prevedibile quando si lavora con configurazioni particolari o database legacy.

Capability Engine: sapere cosa può realmente fare il database

Una delle innovazioni architetturali più importanti della v30 è il nuovo sistema centralizzato delle SQL Capability.

Il progetto dispone ora di un Core che descrive le funzionalità supportate dai vari database.

Tra queste troviamo:

Foreign Key;
Check Constraint;
Views;
Triggers;
Routines;
Sequences;
Lateral;
Apply;
Returning;
Generated Columns;
JSON;
Pagination;
altre funzionalità specifiche.

Il Builder può quindi basare la generazione SQL sulle funzionalità disponibili invece di utilizzare esclusivamente controlli basati sul nome del database.

Perché le Capability sono così importanti?

Consideriamo un esempio.

Non è sufficiente sapere:

Database = SQL Server

Bisogna sapere anche:

SQL Server
+
versione
+
sessione
+
feature disponibili

Una funzionalità può infatti essere stata introdotta soltanto in una determinata versione.

Per questo PlyxSQL v30 considera la versione del server come parte integrante del contesto SQL.

Server Profile

Il SQL Builder utilizza un profilo server più completo attraverso il concetto di:

TSQLServerProfile

Il profilo combina:

dialetto;
prodotto;
versione;
capability;
sessione.

Questo permette al generatore SQL di prendere decisioni molto più precise.

Il risultato è un Builder più consapevole dell'ambiente nel quale sta operando.

SQL Builder più intelligente

Il Builder è stato profondamente migliorato nella gestione delle funzioni SQL.

In particolare sono stati introdotti contratti espliciti per le funzioni scalari.

Una funzione può essere:

nativa;
emulata;
non supportata;
dipendente dalla versione.

Questo è molto più sicuro rispetto a supporre che una funzione con lo stesso nome abbia necessariamente lo stesso comportamento su tutti i database.

Supporto specifico per DB2

DB2 presenta numerose particolarità sintattiche.

La v30 introduce un renderer specifico per le funzioni scalari DB2.

Questo consente di gestire in modo dedicato funzioni relative a:

stringhe;
lunghezza;
substring;
padding;
funzioni numeriche.

Il Builder non deve quindi trattare DB2 semplicemente come una variante generica dello standard SQL.

Supporto specifico per Informix

Anche Informix dispone di una gestione dedicata per le funzioni scalari.

Questa scelta consente di produrre SQL maggiormente aderente alle caratteristiche del database.

È un passaggio importante per un prodotto che vuole supportare realmente anche database meno diffusi rispetto ai classici MySQL, PostgreSQL e SQL Server.

Supporto specifico per Microsoft Access

Microsoft Access rappresenta un ambiente particolarmente diverso rispetto ai database server tradizionali.

La v30 introduce una gestione specifica delle sue funzioni SQL e delle sue peculiarità.

Questo permette di evitare di utilizzare automaticamente la sintassi dei database server-oriented.

Pagination cross-database

La gestione della paginazione SQL è stata resa più robusta.

Sono stati affrontati in particolare:

offset negativi;
overflow;
conversione dei valori;
differenze tra database;
sintassi specifiche dei vari dialetti.

La generazione della paginazione viene quindi effettuata tenendo conto delle caratteristiche del database.

Quoting degli identificatori

Il quoting è un'altra area particolarmente delicata in un ambiente SQL multi-database.

PlyxSQLv30 dispone di una gestione più strutturata del quoting.

Questo consente di tenere conto delle differenze tra:

SQL Server;
PostgreSQL;
MySQL;
MariaDB;
Firebird;
InterBase;
Access;
altri dialetti supportati.

Il quoting viene quindi trattato come una caratteristica del contesto SQL e non come una semplice operazione testuale.

DDL: una nuova architettura unificata

La gestione del DDL è stata completamente riorganizzata.

La v30 introduce una struttura composta da:

SQL DDL Service
DDL Generator
SQL DDL IR

L'utilizzo di un modello intermedio consente di separare la descrizione dell'oggetto dalla sintassi specifica del database.

Questo rende la generazione DDL più facilmente estendibile.

DDL coerente tra Tree e Designer

Una delle migliorie più importanti è la maggiore uniformità tra le operazioni effettuate dal Tree Explorer e quelle effettuate dallo Schema Designer.

La stessa architettura DDL viene utilizzata per le diverse modalità operative.

Questo riduce il rischio di avere:

SQL differente a seconda del punto dell'applicazione dal quale viene eseguita la stessa operazione.

Foreign Key, Index e Constraint

La gestione degli oggetti strutturali del database è stata migliorata.

Particolare attenzione è stata dedicata a:

Foreign Key;
Index;
Constraint;
Check Constraint;
quoting;
nomi degli oggetti;
riferimenti tra tabelle;
differenze DDL tra database.

La capability matrix permette inoltre di distinguere meglio ciò che un database può realmente eseguire.

Trigger più accurati

La gestione dei trigger è stata resa più precisa.

In particolare vengono considerate le differenze relative ai trigger:

INSTEAD OF

che non sono disponibili allo stesso modo in tutti i database.

Questo evita di trattare tutte le implementazioni dei trigger come equivalenti.

Routine e cataloghi database

La gestione delle routine è stata migliorata attraverso una classificazione più precisa degli oggetti restituiti dai cataloghi database.

Questo consente di distinguere meglio:

procedure;
funzioni;
routine;
differenti tipologie catalogate dai vari DBMS.

Il Tree Explorer può quindi rappresentare gli oggetti in modo più coerente.

SQLite e le sue particolarità DDL

SQLite non dispone dello stesso modello DDL dei database server tradizionali.

La v30 gestisce esplicitamente le limitazioni relative alle constraint e alle operazioni DDL.

In particolare vengono evitate operazioni che SQLite non può eseguire direttamente con la stessa modalità di altri database.

SQL Script Runner

La gestione degli script SQL è stata centralizzata attraverso il nuovo:

SQLScriptRunner

Il sistema gestisce:

analisi;
suddivisione;
pianificazione;
esecuzione;
gestione degli errori.

Questo permette di avere una pipeline SQL più coerente.

SQL Script Splitter

La suddivisione degli script è stata migliorata per gestire correttamente le singole istruzioni.

Questo è particolarmente importante quando uno script contiene strutture SQL più complesse.

La separazione tra parsing dello script e sua esecuzione permette inoltre di migliorare progressivamente il motore senza dover modificare tutte le funzionalità che utilizzano SQL.

Esecuzione DDL asincrona

Le operazioni DDL possono essere eseguite attraverso un modello asincrono.

Questo è fondamentale per database:

remoti;
lenti;
con molti oggetti;
soggetti a lock;
con operazioni DDL lunghe.

L'interfaccia può quindi rimanere reattiva durante le operazioni più pesanti.

SQL Execution Matrix

Una delle funzionalità più interessanti della v30 è la:

SQL Execution Matrix

Non ci si limita a verificare che il Builder produca una stringa.

Le query possono essere eseguite realmente sul database.

La matrice verifica attualmente diverse categorie, tra cui:

funzioni scalari;
quoting;
pagination;
coerenza del dialetto.

Questo introduce un concetto molto importante:

testare SQL realmente eseguibile e non soltanto SQL apparentemente corretto.

Dal test statico al test reale

Un SQL Builder può produrre una query apparentemente perfetta:

SELECT ...

ma soltanto il database può confermare se quella query è realmente valida.

La SQL Execution Matrix introduce quindi una verifica concreta del comportamento del generatore.

È un passo fondamentale verso un ambiente SQL professionale.

Sincronizzazione Tree Explorer, Builder ed Editor

La v30 migliora il collegamento tra i tre componenti principali:

Tree Explorer

Gestisce le connessioni e il Workspace.

SQL Builder

Genera SQL sulla base del Workspace.

SQL Editor

Visualizza e modifica il codice SQL.

Il flusso diventa quindi:

CONNESSIONE
     ↓
TREE EXPLORER
     ↓
WORKSPACE
     ↓
BUILDER
     ↓
SQL
     ↓
EDITOR

Questo rende l'interazione tra i componenti molto più prevedibile.

SQLManagerMenu come orchestratore

SQLManagerMenu rimane il centro operativo dal quale vengono avviate numerose funzioni.

La nuova architettura, però, riduce progressivamente la quantità di logica duplicata all'interno del menu.

Il menu coordina le operazioni mentre il Workspace e i servizi specializzati gestiscono le informazioni SQL.

Questa separazione rende il progetto più facilmente manutenibile.

Cache e invalidazione del contesto

La gestione della cache è stata integrata con il concetto di generazione del Workspace.

Quando cambia il contesto della connessione, le informazioni precedenti possono essere invalidate.

Questo è particolarmente importante quando l'utente passa rapidamente tra database differenti.

Ad esempio:

PostgreSQL
   ↓
SQL Server
   ↓
Firebird
   ↓
MariaDB

senza riavviare l'applicazione.

Gestione delle versioni server

La versione del server è diventata una componente importante del modello SQL.

Questo consente di gestire meglio le differenze tra:

MySQL 5.7
MySQL 8.x

oppure:

SQL Server legacy
SQL Server moderno

e analogamente per gli altri DBMS.

Questa impostazione è fondamentale per evitare che il Builder consideri automaticamente tutte le versioni di un database equivalenti.

Una vera architettura Cross-Dialect

La v30 non si limita quindi a tradurre:

SQL standard → SQL database

L'approccio è più evoluto:

Workspace
    ↓
Dialect
    ↓
Product
    ↓
Version
    ↓
Session
    ↓
Capabilities
    ↓
Renderer
    ↓
SQL

Questo rappresenta un modello molto più vicino a un vero SQL compiler/generator cross-database.

Perché la v30 è importante

La vera innovazione della versione 30 non è una singola funzione.

È il modo in cui le diverse funzionalità sono state collegate.

La piattaforma dispone ora di una catena architetturale molto più coerente:

Connection → Workspace → Capability → Renderer → SQL → Execution

Questo permette di costruire in futuro funzionalità ancora più sofisticate senza dover duplicare continuamente la logica per ogni database.

I database supportati

L'architettura v30 è progettata per lavorare con numerosi DBMS, tra cui:

Firebird;
InterBase;
PostgreSQL;
MySQL;
MariaDB;
Microsoft SQL Server;
Oracle;
SQLite;
IBM Db2;
Informix;
Microsoft Access.

Il valore dell'architettura sta proprio nella capacità di gestire le differenze tra questi ambienti mantenendo un modello comune.

PlyxSQL v30 rappresenta una delle evoluzioni architetturali più importanti del progetto.

Il passaggio fondamentale è quello da una gestione SQL basata principalmente sul semplice dialetto a una gestione basata sul contesto completo:

Database + Product + Version + Session + Capability + Renderer

Questo approccio permette di affrontare in modo molto più professionale la complessità del mondo SQL.

Il Builder non deve più semplicemente chiedersi:

"Quale database sto utilizzando?"

ma deve poter rispondere a una domanda molto più precisa:

"Quale sintassi SQL è realmente disponibile in questo specifico ambiente?"

È questa filosofia che rende la v30 una piattaforma particolarmente interessante per lo sviluppo di applicazioni database multi-DBMS.

#SQL #database #ETL #DataEngineering #plyxSQL #FireDAC #PGSOFT

mercoledì 7 ottobre 2026

Free PlyxSQL© - 1.0.0.109 Bug fix

PlyxSQL 109 – Report dei bug risolti e miglioramenti implementati

Introduzione

Durante le ultime attività di sviluppo e revisione del progetto PlyxSQL, sono stati individuati e corretti numerosi problemi che riguardavano la gestione dei database, la compatibilità SQL tra diversi DBMS, l'esecuzione delle query, il Query Builder, l'Editor SQL, l'autenticazione e le operazioni asincrone.

L'obiettivo principale degli interventi è stato rendere l'applicazione più affidabile e coerente quando lavora con database differenti, evitando che una funzionalità corretta per un DBMS producesse comportamenti errati su un altro. Particolare attenzione è stata dedicata alla gestione dei dialetti SQL, alle informazioni sulla versione del server e alle differenze tra i vari database supportati.

Questo documento riassume i principali bug già risolti.

1. Corretto il problema del contesto SQL tra Editor, Core e Query Builder

Uno dei problemi più importanti riguardava la gestione del contesto SQL. In precedenza alcune funzionalità potevano utilizzare informazioni diverse sul database corrente a seconda del componente che le eseguiva.

Il problema è stato corretto introducendo una gestione più strutturata del contesto del server e del dialetto SQL. Il sistema ora distingue in modo più affidabile:

DBMS
versione del server
major/minor/patch
build
update
compatibilità
caratteristiche specifiche del database
impostazioni della sessione SQL

Questo permette all'Editor, al SQL Core e al Query Builder di lavorare con informazioni coerenti.

2. Corretto il problema del RETURNING

È stata corretta la gestione della clausola RETURNING. Il supporto non viene più trattato genericamente per tutte le operazioni DML. La gestione è stata separata per:

INSERT
UPDATE
DELETE

Questo evita di generare SQL non valido quando un particolare DBMS supporta RETURNING soltanto per alcune operazioni. La capability viene quindi valutata in funzione del dialetto e dell'operazione effettivamente richiesta.

3. Corretta la gestione di PostgreSQL LATERAL

È stato corretto il supporto a LATERAL per PostgreSQL. La gestione tiene conto della versione del database, evitando di generare SQL con funzionalità non disponibili sulle versioni più vecchie.

Questo è particolarmente importante per PostgreSQL 9.3 e versioni successive, dove la disponibilità della funzionalità deve essere verificata in relazione alla versione del server.

4. Migliorata la gestione del dialetto Firebird/InterBase

È stata rivista la gestione delle differenze tra Firebird e InterBase. Il sistema ora dispone di una gestione più specifica del dialetto SQL invece di trattare indistintamente tutti i database appartenenti alla stessa famiglia.

Questo ha permesso di migliorare:

quoting degli identificatori
generazione SQL
rilevamento del DBMS
gestione delle capability
gestione della versione
comportamento del Query Builder

5. Corretta la gestione delle impostazioni sql_mode

Per MySQL e MariaDB è stata aggiunta una gestione più accurata delle impostazioni di sessione. Vengono considerate impostazioni come:

ANSI_QUOTES
NO_BACKSLASH_ESCAPES
PIPES_AS_CONCAT

Queste impostazioni possono modificare concretamente il significato del codice SQL. La loro rilevazione permette quindi al motore SQL di evitare di interpretare sempre le stringhe e gli identificatori secondo un'unica sintassi.

6. Corretta la gestione della versione Oracle

È stata corretta la rilevazione della versione Oracle. Il sistema ora dispone di informazioni più precise sulla versione del server e può utilizzarle per determinare la disponibilità delle funzionalità SQL.

Questo evita che il generatore SQL utilizzi automaticamente funzionalità appartenenti a versioni più recenti del database.

7. Corretta la gestione dei BLOB/Base64

È stata migliorata la conversione dei dati BLOB in Base64. La gestione precedente poteva produrre risultati errati con determinati dati binari. La conversione è stata resa più robusta, evitando problemi nella rappresentazione e nell'esportazione dei dati binari.

8. Corretta la gestione dei numeri con separatori delle migliaia

È stato corretto il parsing dei valori numerici contenenti separatori delle migliaia. Il sistema distingue ora meglio tra:

separatore decimale
separatore delle migliaia
formato numerico specifico del database

Questo evita che un valore numerico venga interpretato come un numero differente oppure come una stringa.

9. Corretto il funzionamento asincrono dello Schema Compare

È stato corretto il funzionamento asincrono delle operazioni di Schema Compare. Le operazioni più pesanti non devono bloccare inutilmente l'interfaccia grafica.

Sono stati inoltre migliorati:

gestione dei task asincroni
aggiornamento dell'interfaccia
gestione della cancellazione
sincronizzazione dei risultati

10. Corretta la gestione degli errori durante l'introspezione

È stata migliorata la gestione degli errori durante le operazioni di introspezione del database. Gli errori non vengono più ignorati indiscriminatamente.

Questo permette di distinguere meglio tra:

oggetti realmente assenti
oggetti non supportati
errori SQL
errori di connessione
problemi di permessi

Il risultato è una diagnostica più affidabile.

11. Corretta la gestione dei nomi SQL non escapati

Sono stati corretti diversi casi in cui i nomi di database, schema, tabelle, colonne e oggetti SQL potevano essere utilizzati senza un corretto escaping.

La generazione SQL utilizza ora le regole di quoting appropriate per il dialetto. Questo è fondamentale quando un identificatore:

contiene spazi
contiene caratteri speciali
coincide con una parola riservata
utilizza maiuscole/minuscole significative

12. Corretta la gestione del tokenizer per le REST table

È stato corretto il tokenizer utilizzato nella gestione delle REST table. Il parser ora gestisce meglio le strutture SQL/API contenenti caratteri e delimitatori che precedentemente potevano essere interpretati in modo errato.

Questo riduce gli errori durante il parsing delle definizioni.

13. Corretto il calcolo dell'ultima pagina dei risultati

È stato corretto il problema relativo al calcolo di hasMore nell'ultima pagina dei risultati. In precedenza il sistema poteva indicare erroneamente la presenza di ulteriori record anche quando era già stata raggiunta l'ultima pagina.

La logica ora tiene conto correttamente del numero effettivo di record disponibili.

14. Corretta la gestione dei contatori a 64 bit

È stata migliorata la gestione dei contatori utilizzati per:

COUNT
offset
limit
paginazione
numero di record

I valori vengono gestiti con maggiore attenzione anche quando superano i limiti tipici degli interi a 32 bit. Questo evita overflow e conversioni errate durante le operazioni su grandi quantità di dati.

Sono state rimosse/evitate situazioni in cui credenziali sensibili potevano essere esposte attraverso codice o configurazioni utilizzate durante il debugging.

L'obiettivo è impedire che username e password reali vengano accidentalmente inseriti nel codice sorgente o nei log di sviluppo.

16. Corretta la gestione del SessionKey

È stato corretto il problema relativo alla gestione del SessionKey. La sessione viene ora identificata in modo più coerente evitando collisioni o associazioni errate tra connessioni differenti.

Questo è particolarmente importante per le operazioni asincrone e per quelle che utilizzano più connessioni contemporaneamente.

17. Migliorata la rilevazione delle capability runtime di SQLite

È stata migliorata la gestione delle funzionalità disponibili a runtime in SQLite. In particolare vengono rilevate capability come:

JSON1
REGEXP

Questo permette di distinguere tra ciò che SQLite supporta teoricamente e ciò che è effettivamente disponibile nella build/runtime utilizzata.

18. Corretta la distinzione tra MySQL e MariaDB

È stata corretta la gestione della famiglia MySQL/MariaDB. Il sistema non si basa più esclusivamente sul nome del driver, ma considera anche le informazioni restituite dal server.

Questo permette di distinguere correttamente:

MySQL
MariaDB

La distinzione è importante perché i due DBMS possono avere differenze di sintassi e di capability nonostante la compatibilità generale.

19. Migliorata la gestione di DB2 e Informix nel Core e nell'Editor

È stata introdotta una gestione dedicata di DB2 e Informix nel SQL Core e nell'Editor. Questo evita che questi database vengano trattati semplicemente come SQL standard.

Il sistema dispone ora di regole specifiche per:

riconoscimento del dialetto
capability
quoting
paginazione
generazione SQL

Nel Query Builder il supporto rimane volutamente più limitato per le funzionalità che richiedono una conoscenza completa del dialetto.

20. Centralizzata la matrice delle capability SQL

È stata introdotta una matrice centralizzata per le capability dei vari DBMS. Il sistema dispone ora di regole che permettono di stabilire se una funzionalità è:

supportata
non supportata
supportata in modo condizionale
disponibile a partire da una determinata versione

Questo riduce la quantità di controlli sparsi nel codice e rende più coerente il comportamento dei vari componenti.

21. Distinta la generazione SQL nativa da quella emulata

È stata introdotta una distinzione più chiara tra:

funzionalità SQL native del database
funzionalità emulate dall'applicazione

Questo è importante perché il generatore SQL non deve presentare come nativa una funzionalità che in realtà viene ottenuta attraverso una trasformazione o un'emulazione.

22. Migliorata la gestione della paginazione dell'Editor

La paginazione dell'Editor è stata rivista utilizzando un approccio più strutturato. Il sistema distingue le strategie di paginazione in base al DBMS e cerca di utilizzare la sintassi corretta per ciascun database.

Sono state inoltre migliorate le operazioni di:

COUNT
OFFSET
LIMIT
gestione dell'ultima pagina
rilevamento della presenza di ulteriori record

23. Corretta la paginazione specifica di Firebird nel Query Builder

È stato corretto un problema nella generazione della paginazione Firebird quando veniva utilizzato SELECT DISTINCT. La posizione delle clausole SQL è stata corretta affinché la query generata rispettasse la sintassi prevista da Firebird.

24. Corretto il problema della paginazione DB2/Standard

È stato corretto un problema per cui la richiesta di una paginazione poteva essere ignorata e produrre SQL senza LIMIT/OFFSET o equivalente. La generazione è stata aggiornata per gestire correttamente le strategie supportate dal database.

25. Corretto un problema di invalidazione dei puntatori in DBTagCompare

È stato corretto un problema di gestione della memoria in DBTagCompare. Una struttura utilizzava riferimenti/puntatori verso elementi di un container che potevano essere invalidati quando il container veniva modificato.

Il codice è stato corretto evitando di mantenere riferimenti non più validi agli elementi. Questo elimina un potenziale comportamento indefinito e possibili crash.

26. Corretto un problema di gestione dell'utente corrente

È stato corretto un problema relativo a FCurrentUser nel sistema di autenticazione. La precedente implementazione poteva conservare un puntatore verso un elemento di una struttura dinamica dopo una modifica della struttura stessa.

La gestione è stata resa più sicura evitando riferimenti dangling.

27. Resa cancellabile l'importazione dello Schema Designer

L'importazione nello Schema Designer è stata resa:

asincrona
cancellabile
più sicura rispetto al blocco dell'interfaccia

Questo consente di interrompere operazioni lunghe senza lasciare l'applicazione in uno stato inconsistente.

28. Corretta la gestione degli errori di ReadStoredProcs

Gli errori durante la lettura delle stored procedure non vengono più semplicemente ignorati. Il sistema ora mantiene una maggiore visibilità sull'errore riscontrato durante l'introspezione.

Questo permette di distinguere meglio tra assenza di stored procedure e impossibilità di leggerle.

29. Migliorato il lint dell'Editor SQL

Il lint dell'Editor è stato aggiornato per considerare correttamente il contesto SQL. Questo evita falsi positivi generati quando il codice SQL veniva analizzato senza conoscere il database e il dialetto effettivamente utilizzato.

30. Corrette dichiarazioni mancanti nel sistema di autenticazione

Sono state corrette alcune dichiarazioni relative al sistema di autenticazione/header. Questo ha eliminato problemi di compilazione e di visibilità delle funzioni tra i diversi moduli.

Risultato complessivo

Gli interventi hanno portato a un miglioramento significativo dell'architettura del progetto. Le aree che hanno ricevuto i miglioramenti più importanti sono:

SQL Dialect Engine: il sistema è ora maggiormente consapevole del DBMS e della relativa versione.
SQL Core: le regole SQL sono state centralizzate e rese più coerenti tra i vari componenti.
Query Builder: la generazione SQL è stata migliorata per diversi DBMS, soprattutto per quanto riguarda capability e paginazione.
Editor SQL: sono stati corretti problemi relativi a paginazione, lint, conteggi e contesto SQL.
Schema Compare: sono state migliorate le operazioni asincrone, la gestione degli errori e l'introspezione.
Autenticazione: sono stati corretti problemi di lifetime e gestione delle informazioni di sessione.
SQLite: sono state aggiunte verifiche delle capability effettivamente disponibili a runtime.
MySQL/MariaDB: è stata migliorata la distinzione tra i due database e la gestione delle modalità SQL della sessione.

Il lavoro di revisione ha eliminato un numero significativo di bug e ha soprattutto migliorato la struttura interna del progetto. Il risultato più importante non è soltanto la correzione dei singoli errori, ma la costruzione di una base più solida per la gestione dei differenti DBMS.

La gestione del dialetto SQL è diventata progressivamente più centralizzata e consapevole del contesto del server, della versione e delle capability disponibili. Questo permette a SQL Manager di produrre SQL più affidabile e riduce il rischio che una funzionalità corretta su un database venga erroneamente applicata a un altro.

Restano naturalmente alcune aree di miglioramento, in particolare nella completa uniformità del contesto SQL tra tutti i componenti e nell'introspezione avanzata di alcuni DBMS. Tali aspetti appartengono però alla fase successiva di sviluppo e non fanno parte dell'elenco dei bug già risolti riportato in questo documento.

#SQL #database #ETL #DataEngineering #plyxSQL #FireDAC #PGSOFT

lunedì 5 ottobre 2026

il generatore SQL diventa più affidabile, consapevole e pronto per la produzione

Con la versione 108, PlyxSQL compie un importante passo avanti nella qualità del proprio generatore SQL. Non si tratta soltanto di una serie di correzioni puntuali: è un consolidamento strutturale che rende la generazione delle query più precisa, più sicura e più consapevole delle differenze reali tra i database supportati.

Un generatore che conosce il database

Generare SQL non significa soltanto comporre testo sintatticamente corretto. Ogni database ha regole proprie: nomi qualificati, quoting, JOIN, funzioni, locking, tipi di dato, RETURNING, MERGE, PIVOT e molte altre caratteristiche.

La versione 108 introduce un approccio più maturo: il generatore non si limita più a produrre una query, ma valuta se quella query è realmente supportata dal database di destinazione, con quale sintassi e con quali eventuali differenze semantiche.

SQL più corretto e strutturato

Sono stati corretti diversi aspetti fondamentali della generazione degli statement SQL:

Il terminatore ; viene ora aggiunto una sola volta, anche in presenza di UNION, CTE, INTERSECT, EXCEPT e commenti finali.
I JOIN sono generati tramite un JoinTree esplicito, con gestione corretta di JOIN multipli, annidati, CROSS JOIN, LATERAL e APPLY.
I cicli nelle relazioni non sono più considerati automaticamente un errore, perché possono essere perfettamente leciti in un modello dati.
La validazione è stata resa più chiara, distinguendo la validità della query dalla presenza effettiva di errori.

Identificatori, schemi e quoting

Una delle aree più delicate nella generazione SQL è la gestione dei nomi: tabelle, colonne, alias, schemi, cataloghi e oggetti DDL.

PlyxSQL 108 introduce un quoting centralizzato e un modello strutturato per i nomi qualificati. Il sistema riconosce ora correttamente forme come:

schema.table
database.schema.table
server.database.schema.table
identificatori già delimitati
Oracle database link

Inoltre, la qualificazione di catalogo e schema viene applicata solo quando è effettivamente supportata dal database di destinazione.

JOIN e capability per dialetto

Non tutti i database supportano gli stessi tipi di JOIN nello stesso modo. La nuova gestione delle capability distingue sintassi supportata, dipendente dalla versione e non supportata.

Sono stati migliorati in particolare INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN, CROSS JOIN, LATERAL e APPLY. È inoltre possibile associare predicati JOIN più articolati, utili per condizioni composte, intervalli di date e JOIN non equi.

Locking più consapevole

Il locking è un altro punto in cui le differenze tra database diventano decisive. La versione 108 introduce un rendering dedicato per i lock, con supporto a:

FOR UPDATE
FOR SHARE
SKIP LOCKED
SQL Server UPDLOCK, ROWLOCK e READPAST
Firebird WITH LOCK

Il sistema distingue ora tra traduzione esatta, approssimata e non disponibile. Questo evita di presentare come equivalenti meccanismi di locking che, in realtà, hanno semantiche diverse.

CTE, GROUP BY e funzioni avanzate

Sono state migliorate anche le aree più espressive del linguaggio SQL:

Corretto il posizionamento di RECURSIVE nelle CTE.
Aggiunte capability specifiche per GROUP BY, ROLLUP, CUBE e GROUPING SETS.
Migliorata la gestione di STRING_AGG con DISTINCT e ORDER BY.
Suddiviso il supporto JSON in funzioni distinte, invece di un’unica generica capability.
Introdotto il controllo delle capability runtime, utile ad esempio per REGEXP in SQLite.

Server Profile e versioni del database

Una novità importante è il Server Profile: il generatore può ora valutare le capability non solo in base al dialetto, ma anche in base alla versione effettiva del server.

Questo permette di scegliere la sintassi più appropriata per MySQL, MariaDB, PostgreSQL, SQL Server, Oracle, Firebird, InterBase e SQLite, tenendo conto di versione, compatibility level e configurazione runtime.

MERGE, UPSERT, RETURNING e OUTPUT

La generazione DML è stata notevolmente rafforzata:

MERGE Oracle con sintassi e comportamenti specifici.
Distinzione chiara tra MERGE da valori e MERGE da tabella.
UPSERT corretto per tabelle con sole colonne chiave.
UPSERT version-aware per MySQL e MariaDB.
RETURNING e OUTPUT valutati separatamente per INSERT, UPDATE e DELETE.

Sicurezza nelle operazioni DML

La versione 108 introduce un vero DML Safety Engine. Le operazioni UPDATE e DELETE vengono classificate come:

Safe
Warning
Dangerous

Non si tratta di un semplice commento SQL: il rischio viene valutato e segnalato tramite un evento dedicato, aiutando a prevenire operazioni distruttive accidentali.

Metadati, tipi e colonne speciali

Il mapping dei tipi è stato migliorato con un percorso a tre fasi:

TIPO SORGENTE → TIPO CANONICO → TIPO DIALETTO

Sono inoltre stati migliorati il riconoscimento delle colonne identity, computed e read-only, la loro esclusione automatica da INSERT, UPDATE e MERGE quando non devono essere valorizzate, e la generazione di identificatori sicuri per PK, FK, indici, sequence e trigger.

Importazione, serializzazione e UI più stabili

Oltre al motore SQL, la versione 108 porta numerosi miglioramenti di robustezza:

Gestione più sicura del ciclo di vita del worker di importazione.
Migliore gestione di connessioni, filtri, encoding e diagnostica.
Deserializzazione JSON più atomica e resistente a dati incompleti o non validi.
Correzioni su drag & drop multiplo, paginazione, resize, doppio click, cambio tab e sincronizzazione dell’albero.
Rimozione di chiamate potenzialmente pericolose a ProcessMessages, riducendo rischi di reentrancy e stati UI incoerenti.

Regressione automatizzata

La versione 108 introduce anche una base importante per la qualità futura del prodotto: una suite di regressioni automatizzate con 34 casi per 7 dialetti, per un totale di 238 combinazioni SQL.

I test coprono SELECT, JOIN, CTE, UNION, window function, paginazione, RETURNING, MERGE, JSON, funzioni data e stringa, DDL, foreign key, PIVOT, UNPIVOT, tabelle temporanee, viste e locking.

PlyxSQL 108 non è solo una release di bug fix: è una release di consolidamento. Il generatore SQL diventa più preciso, più consapevole delle differenze tra database, più sicuro nelle operazioni DML e più stabile nell’interfaccia e nei processi di importazione.

Il risultato è un prodotto più adatto a scenari reali, dove la correttezza sintattica non basta: serve sapere che la query generata è realmente compatibile, semanticamente coerente e sicura per il database su cui verrà eseguita.