MySQL: query di confronto date su campi varchar

(No Ratings Yet)

 Loading ...

Posted by raphe | Filed under Programming, Varie

Se per qualche ragione avete un database MySQL in cui ci sono dei campi data il cui formato non è “date” ma testo normale (ad es. “varchar”, “char”, ecc.) e volete comunque effettuare delle query di ricerca filtrando per data, potete combinare due funzioni di MySQL che fanno proprio al caso vostro.

Le funzioni sono:

• DATE_FORMAT che formatta una data in una sintassi da voi stabilita;
• STR_TO_DATE che converte una stringa in una data in formato MySQL (YYYY-mm-dd).

Vediamo un esempio:

supponiamo di avere un campo che si chiama “data_nascita” che è un varchar e contiene la data in formato dd/mm/YYYY, ecco come effettuare la query:

SELECT data_nascita,DATE_FORMAT(STR_TO_DATE(data_nascita,'%d/%m/%Y'),'%Y-%m-%d')

FROM utenti;


In questo modo otterremo due colonne, una con la data in formato originale e l’altra con la data in formato MySQL.

Se ad esempio vogliamo cercare tutte le persone nate prima del 2000 potremmo scrivere qualcosa del genere:

SELECT *

FROM utenti

WHERE DATE_FORMAT(STR_TO_DATE(data_nascita,'%d/%m/%Y'),'%Y-%m-%d')<'2000-01-01'

In ogni caso ricordate che è buona norma avere i campi data in formato “date”. Questo velocizzerà le query di ricerca. Se possibile convertite gli eventuali campi varchar in campi date.

Il processo creativo delle meraviglie apple

(No Ratings Yet)

 Loading ...

Posted by redsend | Filed under Apple, Appunti

Non so’ se sarà un articolo vecchio e quindi già noto a tutti, ma proprio oggi mi è capitato di leggerlo e lo trovo molto interessante.

Perché i programmi Apple sono meglio disegnati della media e spesso offrono una soluzione originale ai problemi? Un esperto programmatore di Cupertino svela alcuni segreti su sviluppo e progettazione secondo Steve.

Leggi il resto…

Comportamento anomalo in Safari con tag IMG

(No Ratings Yet)

 Loading ...

Posted by redsend | Filed under BugFix

Oggi ho passato più di 6 ore per correggere un bug.

Scrivo questo post per aiutare quei poveri programmatori che si troveranno nella mia stessa situazione. Brevemente spiegherò i sintomi che venivano rilevati nell’applicazione web e poi vi illustrerò da cosa dipendeva il problema e come viene risolto.

I sintomi che si presentavano era un azzeramento anomalo della sessione, venivano resettate alcune variabili in sessione e rigenerati alcuni codici di controllo che quindi compromettevano il flusso tra le pagine web dell’applicazione. I cookie erano impostati correttamente e con durata infinita, quindi non poteva essere un problema di scadenza dei cookie. I file della sessione erano scrivibili e venivano correttamente aggiornati in altri casi e quindi non poteva essere un problema di permessi sui file della sessione, altrimenti l’errore si sarebbe presentato a monte. L’errore accadeva solo utilizzando Safari e con Firefox questo non accadeva, il che complicava ancora di più le cose perché trattandosi di sessioni PHP e quindi di script che vengono eseguiti lato server non aveva alcun senso che su un browser funzionasse mentre sull’altro no.

L’errore che era stato commesso era un tag immagine con l’attributo src uguale a stringa vuota (src=”" per intenderci).

In questo caso Firefox semplicemente eliminava l’immagine dal flusso HTML e quindi non accadeva nulla di strano, mentre Safari, il buono e caro Safari (sto cercando di trattenermi dal rompere tutto), cosa fà? Suppone che per qualche arcano motivo l’immagine inserita senza path si trovi nell’indirizzo della pagina php invocata e quindi effettua un secondo chiamata alla pagina che compromette tutto il funzionamento della sessione PHP e del flusso che stavano seguendo le pagine.

Per farmi capire meglio la pagina chiamata ad esempio era index.php e Safari trovando un tang IMG con src=”" sostituisce all’indirizzo dell’immagine index.php, quindi otteniamo una cosa del genere: src=”index.php”, in che corrisponde ad una seconda invocazione della pagina index.php che potrebbe, come nel mio caso, compromettere il flusso che si stava seguendo attraverso form etc… questo perché, ad esempio, nell’invocazione di index.php senza nessun parametro e sottomissione di form, veniva esegueto l’azzeramento della sessione…

Bhè ottimo lavoro da parte di quelli di Safari per questa emerita scelta progettuale… e spero di aver risparmiato tante ore di debug ad altri poveri programmatori che si troveranno in questa situazione.