Problema campi "date" in mySql

[Mario]

Ehilà!

Ho un problemino dei miei :-)

sto lavorando su una serie di tabelle in mySQL, tre per la precisione, e su due non ho nessun problema (se non la mia inesperienza...)
La terza non sono mai riuscito ad aprirla, ottenendo un errore del tipo "#11".
oggi ho provato a capire, e ho visto che togliendo i campi di tipo "DATE" la tabella viene aperta normalmente.
In questa tabella ho bisogno dei campi di tipo data, perché si tratta di un archivio di interventi, dove la data è indispensabile per la fatturazione.
E' un bug conosciuto? Posso fare qualche "walk around" per evitare il problema?

Tnx

[g.paolo]

Chi lavora come me con sqlite3 sa che i campi data è meglio che se li dimentichi.
Io gestisto i medesimi come testo ed ovviamente il lavoro di formattazione viene sopportato dal codice!
Sarà più impegnativo all'inizio, ma per me è sempre più "trasparente".

[tornu]

Le date in MySql vanno inserite in questo formato:

yyyy-mm-dd

un metodo potrebbe essere di associare una variabile formattata come sopra al campo da cui catturi la data prima di inserirla nel DB.

[Mario]

Grazie ragazzi, adesso provo :-)

[Mario]

Uhm, Tornu, stavo riflettendo sulla tua soluzione.
E' ottima ma temo che il problema sia più grande. Se il mio DB mySQL contiene dei campi di tipo data, mi va in errore Gambas!
A questo punto mi sa che devo tornare alle vecchie abitudini :-)
Su AS/400 da poco sono state inseriti i campi di tipo date (e anche time, e timestamp). Fisicamente sono campi di tipo testo di 10 caratteri (i vari elementi della data, più i separatori), ma il sistema li elabora come, appunto date.
Prima di questa innovazione, e ancora presenti in moltissimi programmi, le date sono memorizzate in formato numerico di 6 o 8 caratteri, a seconda della lunghezza dell'anno.
A questo punto mi faccio un paio di subroutine (volevo dire funzioni) tipo Dt2Num() e Num2Dt() che mi facciano la corretta conversione dal file al video :-)

Quando faccio la prima fattura, festeggiamo!! :-D

Tra l'altro ho anche scaricato e pasticciato un pochino con Sqlite: mi sembra carino e interessante... Oltre tutto ho visto che permette di salvare il DB come un file, comodo per fare salvataggi e compagnia bella :-)

[tornu]

overhill ha scritto:
Uhm, Tornu, stavo riflettendo sulla tua soluzione.
E' ottima ma temo che il problema sia più grande. Se il mio DB mySQL contiene dei campi di tipo data, mi va in errore Gambas!

Dipende da come gestisci le date, ti assicuro che non c'è nessun problema, ti dico questo perchè ci ho sbattuto il "muso" anche io, visto che il mio progetto contiene parecchi campi data e di conseguenza il DB (anchio uso MySQL) tra cui faccio anche dei calcoli.
Io per gestire le date uso dei campi ValueBox come consigliatomi in questo forum, comunque se posti esattamente il problema che hai magari ti viene data una mano a risolvere.
Ciao

[Mario]

ValueBox? Sembra interessante ;-)

Comunque problemi non ne ho, nel senso che provo a fare come ti ho detto (su file numerico di otto e nel programma di tipo "date") e due funzioni che convertono...
Adesso faccio qualche pasticcio e se ho ancora dei problemi, so dove bussare :-)

Grazie

[leo72]

L'uso del campo ValueData potrebbe essere una soluzione.
Un'altra soluzione potrebbe essere quella di far convertire direttamente a Gambas i dati con la funzione CDate() prima di salvarli nel campo del DB.

Personalmente posso dirti che non ho problemi con un mio progetto che sto migrando da SQLite3 a MySQL con i campi data: però non scrivo direttamente i valori, forse sta qui il tuo problema.

[Mario]

Penso anche io: ho ancora un po' di confusione tra .text e .value :-)
Ad esempio, ho usato i campi valuebox di tipo date e sono comodissimi, funzionano molto bene e riesco spostare i dati avanti e indietro da file a video...
Però la stessa cosa non funziona con un valuebox di tipo "number", che non c'è verso di vedere i dati a video (su file li memorizza...)
Boh? :-|