Lista dei bachi (o presunti tali) ancora da sistemare
-----------------------------------------------------

@ = francesco



 > 1) modCA: mi sembra che i nomi di alcuni campi nella stringa SQL siano
 > sbagliati,
 > quindi chiamando il metodo si ottiene un bel syntax error: forse la
 > definizione del tuo DB
 > e' diversa dalla mia?
A me non da nessunissimo problema  e ho controllato anche che le modifiche
avvengano correttamente. Prova gli esempi contenuti in sql.cc e vedi se anche
da te funzionano. Ti allego il mio DB



 > 2) nello scrivere la classe di modifica delle info su un documento, ho dovuto
 > aggiungere
 > 2 nuovi metodi queryInfoCaricoMod e queryInfoScaricoMod: senza modificare i
 > campi
 > che vengono restituiti, controlla il codice SQL perche' sono sicuro che quello
 > di
 > queryInfoScaricoMod l'ho SBAGLIATO


 
 > 3) Meno grave: quando una query al database restituisce una data, la
 > stringa ottenuta con get(i,j) e` nel formato "aaaa-mm-gg"; c'e` un
 > modo per risolvere il problema senza convertire a mano tutte le stringhe
 > in SqlDate (gestendo ovviamente il caso stringa=NULL)?
@ Mi chiedevo se si pu suggerire a mysql il formato che restituisce ma da quello che so non c' niente da fare
@ a meno di non convertire a mano. Il punto  che mysqlresult NON SA quali dei suoi campi sono date e quindi non 
@ si puo intervenire a questo livello. Una patch bruttina potrebbe essere questa: la funzione di query dopo aver 
@ ottenuto il risultato indica a sqlresult quali colonne sono da rigirare. Oppure se fosse possibile sapere il 
@ delle varie colonne in un risultato si potrebbe rendere trasparente il tutto. 



 > A cio` si aggiungono tutti i punti oscuri indicati con "MODIFY:" nei
 > sorgenti; i punti marcati con "UGLY:" segnalano invece toppe funzionali
 > ma brutte a vedersi.
