Select (MySQL) che funziona in locale e non in remoto

[curzio.maria]

zacca94.
La mia osservazione non voleva in alcun modo mettere in dubbio il tuo post, inoltre la possibile confusione generata da un set di caratteri particolari non mi aveva neppure sfiorato, in generale io trovavo il DB già configurato correttamente, ora giustamente devo tener conto anche di questa possibilita'.

Anche questa e' una novita' importante e da tenere a mente.

Grazie.



OPTIME
non conosco il significato di OT ( evidentemente ignoro troppo cose) ... ma si' e' vero il tempo ... sono passati piu' di venti anni dalla mia ultima installazione e ora che sono in pensione, come cantava Guccini non distinguo piu' il falso dal vero... ahime'.

[badaze]

Una cosa in più.
Per il controllo dei dati bisogna convertirli in minuscole (o in maiuscole) poiche di default mysql non fa la differenza tra 'pippo' e 'Pippo' o 'PIPPO'
Quindi senza, si potrebbe inserire più volte la stess e-mail.

[curzio.maria]

Grazie per le risposte, mi scuso per il ritardo ma ero 'fuori porta', non dispongo di un portatile e (vergogna) uso lo smartphone solo per telefonare ... e guardare serie tv.

@badaze. Tutti i campi della tabella sono 'validati'. Nel caso della email trasformo la stringa in minuscolo ( non credo abbia un gran senso ma ... mi piace cosi') in VB era piu' semplice perche' agivo direttamente sul controllo che riceveva l'input, ora devo utilizzare delle funzioni dopo il POST, molta piu' ginnastica per la mente.
Se MySQL non e' case-sensitive pero' la differenza tra PIppo e PIPPO non creerebbe problemi, almeno credo.

@Luca200, grazie per l'attenzione, in effetti il primo a 'constestare' la logica della doppia select sono stato io ... non avevo neppure preso in considerazione la possibilita' da te esposta : doppio controllo su USER e PASSWORD, otto anni di assoluta distanza dai DB fanno evidentemente effetto, e l'eta' non aiuta.

Devo postare l'output di phpinfo ? tutto ? (chiedo conferma perche' di tratta di un listato enorme e credevo ci fossero limiti nelle dimensioni dei messaggi.

Aggiungo pero' una informazione che forse puo' aiutare, come suggerito da @zacca94 (grazie ancora) ho sistemato un po' il codice con la gestione degli errori, ho trovato ottimi suggerimenti in "PHP Missing manual", e in effetti il codice e' funzionante, salva correttamente gli utenti e altrettanto correttamente li estrae con la select. In remoto su 000WebHost continua a non funzionare, su Altervista funziona tutto. Bel mistero.

Grazie e buona serata a tutti.

[badaze]

@badaze. Tutti i campi della tabella sono 'validati'. Nel caso della email trasformo la stringa in minuscolo ( non credo abbia un gran senso ma ... mi piace cosi') in VB era piu' semplice perche' agivo direttamente sul controllo che riceveva l'input, ora devo utilizzare delle funzioni dopo il POST, molta piu' ginnastica per la mente.
Se MySQL non e' case-sensitive pero' la differenza tra PIppo e PIPPO non creerebbe problemi, almeno credo.

Ha senso salvare le email in minuscolo visto che è il tuo identificativo. Pippo@aaa.it non è uguale a PIppo@aaa.it
In generale ha senso salvare o contollare i dati d'identicazione in un unico modo. Esempio : Se c'è un utente badaze non uo' essercene un altro che si chiami Badaze o BaDaZe. Se vuoi che uno possa vedere il suo nick name come l'ha battuto allora fai un controllo sulla tabella : select * from utenti where lower(campo_user_name) = lower($variabile_user_name)
(premettendo che la funzione di conversione in minuscole si chiami lower)

[zacca94]

Boh postalo, mettilo magari fra i tag spoiler così da evitare di allungare la pagina

[curzio.maria]

@badaze ... premesso hai assolutamente ragione e la formattazione dei dati entro canoni stabiliti è importante, concorderai pero' con me che se nella mia tabella USER posso inserire BADAZe badAZE e badAze ... allora ho sbagliato a impostare la tabella.

@luca200 ... non riesco a 'organizzarmi' con i tag quindi vado di brutto :

... errore troppi caratteri.. se mi indichi la sezione o le sezioni d'interesse le posto.

Grazie

[badaze]

@badaze ... premesso hai assolutamente ragione e la formattazione dei dati entro canoni stabiliti è importante, concorderai pero' con me che se nella mia tabella USER posso inserire BADAZe badAZE e badAze ... allora ho sbagliato a impostare la tabella.

@luca200 ... non riesco a 'organizzarmi' con i tag quindi vado di brutto :

... errore troppi caratteri.. se mi indichi la sezione o le sezioni d'interesse le posto.

Grazie

Nel tuo caso specifico l'identificativo è l'indirizzo email e hai scelto (buona scelta) di convertirlo in minuscolo. Ma se l'identificativo fosse un nick name dovresti salvarlo com'è stato digitato confrontandolo con gli altri nick in minuscolo per entrambi dati.

[luca200]

@luca200 ... non riesco a 'organizzarmi' con i tag quindi vado di brutto :

Facciamo prima: che versione usi di php?

[luca200]

Facciamo prima: che versione usi di php?

E che versione c'è sul server dove funziona...

[zacca94]

premesso hai assolutamente ragione e la formattazione dei dati entro canoni stabiliti è importante, concorderai pero' con me che se nella mia tabella USER posso inserire BADAZe badAZE e badAze ... allora ho sbagliato a impostare la tabella

Mah non credo, che codifica di caratteri ti permette di inserire solo minuscole? è normale permettere l'inserimento di badAZE, non è normale non verificare se "badaze" in qualsiasi salsa esista già:

<?php
  // ...
  $new_nick = "BaDAzE";
  $q = mysql_query("SELECT 1 FROM users WHERE LOWER(nick) = LOWER('{$new_nick}') LIMIT 1");
  if (mysql_count($q)) {
    echo "Utente presente";
  }

Comunque per quanto riguarda il tuo hosting su aruba che versione di PHP hai? Puoi fare un echo PHP_VERSION; e vedere se le API di mysql che usi sono valide...
perchè non è per fare il guastafeste ma le comuni funzioni "mysql" sono deprecate.
http://de2.php.net/manual/en/function.mysql-connect.php