mysql_affected_rows fallito per dati non modificati

[CeMax-2000]

salve,

se eseguo una query di update in un database, uso a seguire un mysql_affected_rows per verificare se la query è avvenuta o meno e fin qui tutto bene, ma, se la query non viene eseguita esiste un modo per scoprire il perchè non è stata eseguita??
Più precisamente io vorrei sapere se la query è "fallita" (o considerata tale) solo perchè in realtà i dati non sono variati da come erano in precedenza.

Ringrazio in anticipo

[gm]

Se la query non modifica (o cancella) niente, il comando restituirà sempre 0

[CeMax-2000]

Originariamente inviato da gm
Se la query non modifica (o cancella) niente, il comando restituirà sempre 0

si infatti ma io "dovrei" riuscire a scoprire se restituisce zero perchè non c'è riuscito oppure perchè non ha variato nulla!

in tal caso ho trovato questo articolo dove si dice:

mysql_affected_rows() per una UPDATE non considera i record aggiornati con dati identici a quelli preesistenti. Solo i record realmente modificati vengono conteggiati. Tale comportamento può essere modificato passando il numero 2 come quinto parametro della mysql_connect(): mysql_connect("localhost", "user", "password", false, 2);

Sono andato quindi su php.net per documentarmi ed ho visto che realmente esiste questa possibilità solo che sto cercando di tradurre il tutto ma ci vorrà un poco di tempo....

Praticamente quel parametro "obbliga" a restituire 1 anche se non ha fatto modifiche mentre credo che dia zero se c'è stato un qualsiasi altro errore!! Adesso vedo bene se realmente agisce come ho pensato io .

Per adesso cmq grazie per la risposta.

[luca200]

Sei fuori strada.

Quando fai un comando sql di update, indichi al server MySql quali righe devono essere variate e quali sono i nuovi valori che devono assumere.
Per fare un'ipotesi semplice, diciamo che la tua tabella contiene 100 righe, delle quali 60 rientrano nella selezione di quelle che hai indicato come "da modificare". Può capitare però che 20 di queste 60 abbiano già i valori uguali a quelli che tu hai indicato come nuovi valori da assumere.
In questo caso, mysql_affected_rows() restituirà 40 e non 60, perché sono 40 le righe effettivamente modificate, anche se erano 60 a rientrare nella condizione espressa dalla clausola WHERE.

Per quanto riguarda le "query fallite", non è certo a questa funzione che devi affidarti per scoprire se qualcosa è andato storto.
Quando si lancia una funzione mysql è buona norma (da seguire rigorosamente, come già detto migliaia di volte su questo forum) utilizzare SEMPRE la forma

mysql_query($query,$connessione) or die(mysql_error()); 

E questo, ribadisco, per ogni comando sql, non solo per l'esecuzione di una query.
In questo modo avrai sempre immediatamente la percezione di cosa è andato male e perché.

Per finire, la possibilità di modificare quel comportamento di mysql_affected_rows(), di cui parla quell'articolo, è qualcosa di cui non avevo mai sentito parlare, e di cui non trovo traccia sul sito di php. La pagina della funzione mysql_connect() fa riferimento ad un quinto parametro che contiene flags utente, ma nessuno di questi si riferisce al risultato di mysql_affected_rows(). In sostanza, non conterei troppo su questa possibilità.

[CeMax-2000]

Originariamente inviato da luca200
Per finire, la possibilità di modificare quel comportamento di mysql_affected_rows(), di cui parla quell'articolo, è qualcosa di cui non avevo mai sentito parlare, e di cui non trovo traccia sul sito di php. La pagina della funzione mysql_connect() fa riferimento ad un quinto parametro che contiene flags utente, ma nessuno di questi si riferisce al risultato di mysql_affected_rows(). In sostanza, non conterei troppo su questa possibilità.

Ciao Luca200,

hai ragione su tutti i fronti tranne che uno e cioè quello che ho citato.
Ti spiego; sul php.net si parla eccome di come modificare il comportamento di mysql_affected_rows, infatti se scorri in basso troverai un post dove si elencano una serie di parametri che è possibile inserire ed in fondo allo stesso elenco c'è una postilla dove si dice che non sempre tali "hack" funzionino tranne per CLIENT_FOUND_ROWS ovvero il famoso parametro con valore 2.

riporto qui l'intero post tanto per renderlo utile a chi interessa:

client_flags can be things other than MYSQL_CLIENT_COMPRESS, MYSQL_CLIENT_IGNORE_SPACE and MYSQL_CLIENT_INTERACTIVE.

I presume that mysql_connect() just passes through to the C MySQL API, which provides these constants:

#define CLIENT_LONG_PASSWORD 1 /* new more secure passwords */
#define CLIENT_FOUND_ROWS 2 /* Found instead of affected rows */
#define CLIENT_LONG_FLAG 4 /* Get all column flags */
#define CLIENT_CONNECT_WITH_DB 8 /* One can specify db on connect */
#define CLIENT_NO_SCHEMA 16 /* Don't allow database.table.column */
#define CLIENT_COMPRESS 32 /* Can use compression protocol */
#define CLIENT_ODBC 64 /* Odbc client */
#define CLIENT_LOCAL_FILES 128 /* Can use LOAD DATA LOCAL */
#define CLIENT_IGNORE_SPACE 256 /* Ignore spaces before '(' */
#define CLIENT_CHANGE_USER 512 /* Support the mysql_change_user() */
#define CLIENT_INTERACTIVE 1024 /* This is an interactive client */
#define CLIENT_SSL 2048 /* Switch to SSL after handshake */
#define CLIENT_IGNORE_SIGPIPE 4096 /* IGNORE sigpipes */
#define CLIENT_TRANSACTIONS 8192 /* Client knows about transactions */

Not all of these may work or be meaningful, but CLIENT_FOUND_ROWS does, at least.

In ogni caso non è affidabile in quanto alla fin-fine, sempre se non ho frainteso io, questo benedetto parametro fa si che il comportamento di mysql_affected_rows assuma lo stesso comportamento di mysql_num_rows ovvero è come se ti restituisca il numero dei record trovati.

infine per chiudere, dato che la mia esigenza prevede l'effettuazione di una serie di query che possono essere "SELECT", "UPDATE", "DELETE" ho per il momento optato per la seguente soluzione:

        $TypeQueryExe = substr($query,0,6);

        $DataBaseConnect->query($query);

        $ResultQuery = 0;
        if($TypeQueryExe == "UPDATE") {
          $ResultQuery = 1;
        }
        else
        if( ($TypeQueryExe == "INSERT") || ($TypeQueryExe == "DELETE") ) {
          $ResultQuery = $DataBaseConnect->affected_rows();
        } 

In attesa che mi vengano idee migliori uso questo e poi vedrò di intercettare l'errore con:
or die(mysql_error())
da te giustamente citato.
Saluti ed ancora grazie per i consigli.
Se vi va potete anche continuare a darne che sono sempre utili.

[luca200]

Originariamente inviato da CeMax-2000
Ti spiego; sul php.net si parla eccome di come modificare il comportamento di mysql_affected_rows, infatti se scorri in basso troverai un post dove si elencano una serie di parametri che è possibile inserire ed in fondo allo stesso elenco c'è una postilla dove si dice che non sempre tali "hack" funzionino tranne per CLIENT_FOUND_ROWS ovvero il famoso parametro con valore 2.

Effettivamente non avevo guardato i commenti. A quanto pare chi ha scritto la documentazione ufficiale non aveva voglia di dilungarsi

Originariamente inviato da CeMax-2000
In ogni caso non è affidabile in quanto alla fin-fine, sempre se non ho frainteso io, questo benedetto parametro fa si che il comportamento di mysql_affected_rows assuma lo stesso comportamento di mysql_num_rows ovvero è come se ti restituisca il numero dei record trovati.

Sì, questo è quello che ti avevo spiegato io (con altre parole), ma che significa "non affidabile"? Dipende cosa vuoi farci. Se vuoi usarlo per scovare errori, come ti ho detto, non è certo il mezzo giusto.

[CeMax-2000]

Originariamente inviato da luca200
Effettivamente non avevo guardato i commenti. A quanto pare chi ha scritto la documentazione ufficiale non aveva voglia di dilungarsi

infatti lo credo anch'io

Originariamente inviato da luca200
Sì, questo è quello che ti avevo spiegato io (con altre parole), ma che significa "non affidabile"? Dipende cosa vuoi farci. Se vuoi usarlo per scovare errori, come ti ho detto, non è certo il mezzo giusto.

Infatti....

Per non affidabile intendo che lui restituisce solo il numero di record " trovati " (come per mysql_num_rows) mentre io voglio sapere se lui il record che ha trovato lo ha " anche modificato " e se così non fosse vorrei sapere il perchè non lo ha modificato!!

Lo so a questo punto datemi pure una fettina di natica e poi.......

Sto guardando adesso sul sito di mysql ed ho trovato (credo) l'errore che mi interessa ma non ne sono sicuro:

Error: 1134 SQLSTATE: HY000 (ER_UPDATE_INFO)
Message: Rows matched: %ld Changed: %ld Warnings: %ld

Che ne dici potrebbe essermi utile?? se si come lo devo interpretare??

Grazie e ciao.

[luca200]

Mi sa che non ci capiamo.
Il numero di record "trovati" te lo restituisce modificando il famoso parametro. Altrimenti ti restituisce solo quelli modificati.
In ogni caso, in assenza di errori, il motivo per cui un record trovato non è stato modificato può essere uno solo: conteneva già i valori richiesti dall'aggiornamento.

Se invece ci sono errori, come già detto, devi averli intercettati prima.
Quindi: qual è il problema?! Perché vai a cercare cose strane sul manuale mysql?

[CeMax-2000]

Originariamente inviato da luca200
Mi sa che non ci capiamo.
Il numero di record "trovati" te lo restituisce modificando il famoso parametro. Altrimenti ti restituisce solo quelli modificati.
In ogni caso, in assenza di errori, il motivo per cui un record trovato non è stato modificato può essere uno solo: conteneva già i valori richiesti dall'aggiornamento.

Se invece ci sono errori, come già detto, devi averli intercettati prima.
Quindi: qual è il problema?! Perché vai a cercare cose strane sul manuale mysql?

no luca ci capiamo benissimo perchè appunto il parametro non l'ho più modificato proprio per il fatto che a me in quel modo non serve

Il secondo pezzo del tuo intervento in effetti chiarifica il tutto e mi convince ancora di più del piccolo "hack" che ho applicato facendo in modo che se si tratta di un UPDATE allora il risultato sarà sempre 1 che è quello che mi interessa.

Grazie ancora per i tuoi interventi sempre molto chiarificatori

p.s. Solo per curiosità sia chiaro, ma quell'errore (1134) è o no legato in qualche modo a questo tipo di evento? cioè al fatto che se non aggiorna rende zero?