Stavo provando ad implementare pgDesigner, inserendo le funzionalità per la gestione di database in formato SQLite, e facendo delle prove in Gambas, è uscito un problema, che non capisco se è un errore nelle librerie Gambas oppure mio che non le leggo bene.
A dir la verità, ho provato anche con l'esempio Database, ma il risultato è lo stesso. Con programmi esterni invece funziona tutto, per cui penso proprio che l'anomalia sia dovuta a Gambas.
Il problema è semplice:
a) ho creato una semplice tabella, con ognuno dei campi definiti nei vari formati ammessi in SQLite (parliamo di quelli reali, descritti nella doc ufficiale): TEXT, INTEGER, REAL e BLOB;
b) ho inserito dei dati, rispettando ovviamente i formati;
c) mi connetto al db tramite l'applicazione di esempio;
d) eseguo la query (es. SELECT * FROM table1);
e) determino il nome dei campi;
f) loop all'interno del ResultSet;
g) stampo i campi, convertendoli in stringa (con Str(), tanto per gradire);
risultato:
1) tutti i campi numerici vengono rappresentati con il corretto contenuto;
2) per i campi TEXT viene visualizzato solo il primo carattere;
3) i campi BLOB non si leggono direttamente, ma và bene così.
Andando a fondo al problema, mi sono stampato anche le carattestiche di ogni campo e, sorpresa, per TEXT il valore di Length è sempre ZERO!
Oltre al fatto strano che sia zero, non capisco allora perchè comunque mi prende un carattere! Se è zero... è ZERO. Bho?
Ho fatto le stesse cose andando a leggere le tabelle di sistema all'interno del database, ma il ritorno è lo stesso.
Provando a modificare i tipi, ad esempio TEXT con VARCHAR(50), il risultato è idem con patate.
Non mi pare di aver letto di questa anomalia nei forum, ma mi può anche essere sfuggito.
Vi risulta 'sta cosa ?
Ha, tanto per ribadire il concetto espresso tempo fà qui nel sito: SQLite tratta tutti i campi in formato stringa, e per i formati ammessi ufficialmente (INTEGER, READ e BLOB) usa lo stesso concetto, solo che se si usano le api C per interfacciarlo, queste hanno modalità di conversione interne che ne rendono possibile la gestione. Riguardo l'utilizzo di sintassi, utilizzate in database più blasonati, SQLite usa un metodo interno che ne determina il tipo.
Esempio:
- se si dichiara un campo di una tabella:
VARCHAR(10) <...>
- il tipo viene riconosciuto come stringa, determinandolo dalla stringa "CHAR" contenuta all'interno del tipo (VARCHAR).
- la cosa, come ho scritto, è però fittizzia, in quanto anche una dichiarazione, del tipo:
INTEGER <...>
- viene interpretata come numero, ma all'interno viene comunque memorizzato come stringa
- idem con patate:
NUMBER(10,2) <...>
- la definizione del campo viene accettata, capita come numero, ma sempre memorizzata come stringa.
Questo porta ad un problema importante, ovvero il fatto di scrivere codice alquanto robusto, che non permetta di inserire zozzerie all'interno del db.
Per fare un'altro esempio, deleterio:
- definire un campo DATE o DATETIME;
- provate a scriverci dentro una stringa del tipo "PRRRRRRR";
- l'inserimento verrà effettuato regolarmente, perchè il database non effettua alcun controllo, nè logico nè sintattico e nè di formato sul dati immesso.
Nei database con motore incorporato, questo non certamente fattibile, ma in SQLite, che non è un database basato su motore, la cosa è alquanto prevedibile, e anche un pochino pericolosa (tanto per essere prudenti).
Per quanto mi riguarda, l'unica cosa che differenzia SQLite da un semplice file di testo, è il fatto si supportare una limitata sintassi SQL ma, facendo un paragone al vecchio DBIII (o anche il Clipper), la differenza si nota, e parecchio.
Perdonatemi la lunga spiegazione, ma spero sia utile a qualcuno.
Comunque, spero che qualcuno mi dia una dritta sul perchè del problema che ho riscontrato.
Ciao a tutti!
