MySQL da 4.0 a 5.0

[BrokenToy]

Ciao a tutti,
il mio provider ha di recente aggiornato la versione del MySQL (usava ancora la vecchia 4.0). Prima di fare l'upgrade, mi ha messo una "emulazione" del DATETIME (che è subentrato al vecchio TIMESTAMP) per darmi il tempo di adattare il codice PHP del nostro sito di ecommerce. Una volta che tutto funzionava, sono andato in ferie per 10 giorni. Mi richiamano in sede in fretta e furia perchè un paio di giorni prima che io rientrassi il sito ha cominciato a generare errori sparsi...
Ho contattato subito il provider che mi risponde che dopo la fase di "emulazione" del DATETIME hanno upgradato alla 4.1 e infine alla 5.0. Insiste che i problemi li abbiamo solo noi, tutti gli altri siti in PHP sul loro server funzionano perfettamente.
Ora... sono diversi giorni che cerco di risolvere i problemi, ma dico... se il codice non è stato cambiato, e non è stato cambiato perchè non c'ero fisicamente, è quantomeno strano che tutto quello che funzionava perfettamente adesso è in tilt. Mi sono accorto dal database che da un preciso giorno di luglio cominciano i guai, ma loro dicono che in quella data non hanno fatto assolutamente niente. Mi sono ritrovato pure dei records aggiornati con data 2002-01-01... ma a quell'epoca non esistevano nè la società per la quale lavoro nè tantomeno il sito in questione!
Non mi riesce di venirne fuori... qlc ha qualche idea?
Grazie

[BrokenToy]

Mi spiego meglio.
Il mio provider dice che l'unica cosa che non è compatible è la DATETIME (nel passaggio dal MySQL 4 al 5). Qualcuno sa se ci sono invece altre differenze sostanziali che, soprattutto, non sono compatibili con gli script funzionanti con il MySQL 4 ?

[piero.mac]

http://forum.html.it/forum/showthrea...hreadid=839754

puoi dare un'occhiata al link per vedere le principali modifiche delle funzioni temporali.

l'aspetto piu' visibile e' il formato del timestamp prima yyyymmddhhmmss ed ora yyyy-mm-dd hh:mm:ss esattamente come il DATETIME. Dipende quindi da come utilizzavi il timestamp.

[BrokenToy]

Ti ringrazio.
Ho visto che c'è un bel pò di roba da verificare, ma per lo più riguardano la gestione di data/orario.
Avevo già passato tutto in datetime, e funziova perfettamente. Penso che i problemi siano iniziati quando dall'emulazione della sola datetime il provider ha upgradato alla 4.1 e poi alla 5.0.

Non oso pensare a quali differenze ci possano essere tra 4.0 e 5.0...

[piero.mac]

Originariamente inviato da BrokenToy
Ti ringrazio.
Ho visto che c'è un bel pò di roba da verificare, ma per lo più riguardano la gestione di data/orario.
Avevo già passato tutto in datetime, e funziova perfettamente. Penso che i problemi siano iniziati quando dall'emulazione della sola datetime il provider ha upgradato alla 4.1 e poi alla 5.0.

Non oso pensare a quali differenze ci possano essere tra 4.0 e 5.0...

non sono poi molte... le principali variazioni sulla gestione dei dati temporali sono tra la 4.0.x e la 4.1.3

[BrokenToy]

Originariamente inviato da piero.mac
non sono poi molte... le principali variazioni sulla gestione dei dati temporali sono tra la 4.0.x e la 4.1.3

Già... il problema è che la cosa che mi preoccupa meno sono proprio i dati temporali. Vengono fuori problemi assurdi... ad esempio:

L'amministrazione carica un nuovo prodotto, e funziona tutto perfettamente. Appena viene modificato/aggiornato a volte diventa invisibile alle ricerche ma continua ad esse visibile se vai direttamente nella categoria di appartenenza. Sul database l'articolo non varia, sia che sia funzionante sia che non lo sia... ma da quel momento diventa invisibile alle ricerche (sia lato store sia lato back office) e se provi ad aprire la lista prodotti del produttore di quell'articolo, proprio quell'articolo ti manda in crash la pagina... mentre non succede se apri la categoria in cui è "alloggiato".

[piero.mac]

nella modifica e' proprio uno dei cambiamenti del timestamp. Prima veniva autoaggiornato il primo campo ora se ne possono avere diversi ed a scelta di quale autoaggiornare, L'altro e' il formato.

Poi ci sono nuove condizioni di inserimento dati legati al SQL-MODE. a seconda di come e' settato potresti avere errori ed incongruenze nell'iserimento. Per esempio: numerici obbligatoriamente senza apici di inserimento, id autoincrement da dichiarare come NULL invece che "" vuoto ed altr cosette.

Invisibile alle ricerche... bisogna valutare la query ed il contenuto dei campi.

[BrokenToy]

Questo è, ad esempio, uno script di ricerca:



<?php $sql = "select * from {$config['prefix']}Products";

$_POST['product'] = $_POST['search'];

$sql .= " where name like '%{$_POST['product']}%' or description like '%{$_POST['product']}%'";


mysql_query("insert into {$config['prefix']}Searches (text,query,results) values " .

"('{$_POST['product']}','".addslashes($sql)."','".mysql_num_rows(mysql_ query($sql))."')");


header("Location: {$config['siteaddress']}{$config['maindir']}search.php?s=".mysql_insert_id());

exit;

?>



Funziona perfettamente, ma appena becca un articolo aggiornato, lo rileva (dal database si vede chiaramente che viene rilevato) ma non ne permette la visualizzazione.


Dimenticavo... l'errore che ritorna è sempre il medesimo, in qualsiasi parte del sito:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource

con a seguire il numero di riga dove invariabilmente si trova la mysql_fetch_array() del caso...