Écriture dans les tables

Bonjour,
Je rencontre un problème en utilisation avec ma base mysql.
Je suis sous windows 2003 server avec mysql 5.0
J'exploite la base à partir d'un soft développer en php mais celà n'a pas d'incidence.

Dans ce soft j'ai des fiches que je peux éditer pour les modifier, actuellement lorsque j'edite certaine fiche je ne peux pas enregistrer les informations.

J'ai essaye de switcher sur un autre serveur pour tester et le problème viens bien de droit en ecriture sur mon mysql car sur un autre serveur tout fonctionne parfaitement.

Ce que j'ai fait jusqu'a maintenant:
1- j'ai installer et tester avec mysql 5.0 et 5.1
2- j'ai vérifier que les tables n'etait pas locké en read
3- j'ai sauvegardé puis réinstallé ma base
3- j'ai verifié tous les droits de modification de on user root
4- j'ai créée un nouveau user avec tous les droits pour accéder et modifier la base.

ET pour l'instant rien n'y fait.

Si l'un de vous à un éclair de génie pour régler mon problème je suis preneur.

D'avance merci à tous,

Pour info seul ceraines tables posent problème et pas d'autres

quel message d'erreur obtiens-tu ?

c'est bien celà le problème je n'ai pas de message d'erreur, par contre je viens d'essayer à la main des requetes SQL de select et d'update et ca marche.

donc, soit c'est bien un problème de privilèges, mais ton script PHP ne récupère pas le message d'erreur, soit c'est un problème purement PHP. Je te déplace donc sur le forum PHP & MySQL, et je t'invite à nous donner le code PHP qui devrait faire la mise à jour de tes fiches.

Mon problème est plus compliqué.
Si j'installe la base sur un autre serveur (linux + mysql) et que je fais pointer mon application php sur ce serveur, je n'ai pas le problème.

Conclusion l'erreur ne vient pas de php, de plus j'ai installé un second serveur sous apache pour gérer le php et lorsque ce serveur pointe sur la base "officiel" j'ai le même bug, si je le fais pointer vers la base "serveurlinux" pas de problème.


Donc celà vient bien de mon installation mysql sur mon serveur windows 2003, mais pourquoi? là est la question.

Quand au code php qui gere le tout, n'ayant pas developpé l'application et n'etant pas un spécialiste je vais avoir du mal à vous le donner.

Si tu ne maîtrises pas ton code PHP, ça va être difficile !

En gros, les trois hypothèses que tu as sont :

1. pas de connexion du tout
2. problème de privilèges
3. problème de casse dans les noms d'objets (typique quand on passe de Windows à Linux)

Pour commencer, peux-tu nous donner le login utilisé dans les deux configurations, ainsi que le(s) nom(s) de la base de données ?

j'ai tester avec 2 login
le classique root avec mot de passe
et un second "vtiger" avec mot de passe

le nom de la base dans tous les cas est le même vtigercrm504

J'avais tester également avec une base nommée vtigertest sur mon serveur "officiel" et je rencontrais le même problème.

Pour ce qui est du code le soft est un crm opensource nommé vtiger (d'où le nom des bases)

L'hypothèse 1 n'est pas credible car je peux modifier d'autre fiches sans problèmes, je n'ai que quelques tables sur les 500 de la base qui posent problème

AU passage je te remercie pour ton implication à chercher une solution

je ne suis pas sûr de tout comprendre de ton archi... en gros, tu as un seul serveur PHP, et trois serveurs MySQL ?

serveur Linux : tout est OK
serveur "officiel" Windows : pb sur la mise à jour de certaines tables
serveur Windows alternatif : idem

oui pour faire des test et savoir d'ou venait le problème j'ai monté plein de serveur différent.

en gros j'ai monté 2 serveur Web sous windows avec 2 versions légerement différente du soft et l'un sous IIS l'autre sous apache avec la même version de PHP que j'ai fait pointer vers 2 autres server mysql l'un sous windows l'autre sous linux.

Conclusion des tests dans tous les sens le problèmes vient de la base mysql installé sous windows sur mon serveur "officiel"

Une fois la source identifié j'ai fait d'autres tests, d'abord en créant de nouveaux user mysql et en me connectant avec (user avec tous les droits) mais celà n'a rien changé, puis j'ai regardé si je pouvais écrire directement dans les tables avec des update (j'utilise sqlyog) et celà fonctionne parfaitement.

Donc le problème se pose entre on appli php et le serveur mysql, il y a sur certaine table une erreur, l'appli php pense avoir mis la table à jour (pas de message d'erreur) mais en faite la table n'a pas été modifié.

Par contre si j'update la table à partir de sqlyog, la modif et bien visible dans l'appli php.

J'espere avoir été plus clair.

Pour info nous avons cherché avec l'un des devs de ma boite d'ou vient le problème et nous n'avons pas trouvé.

Peux-tu faire un SHOW CREATE TABLE sur la table en question pour chacun de tes deux serveurs, et copier-coller ici les résultats ?

Serveur "officiel" avec problème:

Citation:

---

CREATE TABLE `vtiger_account` ( `accountid` int(19) NOT NULL default '0', `accountname` varchar(100) NOT NULL default '', `parentid` int(19) default '0', `account_type` varchar(200) default NULL, `industry` varchar(200) default NULL, `annualrevenue` int(19) default '0', `rating` varchar(200) default NULL, `ownership` varchar(50) default NULL, `siccode` varchar(50) default NULL, `tickersymbol` varchar(30) default NULL, `phone` varchar(30) default NULL, `otherphone` varchar(30) default NULL, `email1` varchar(100) default NULL, `email2` varchar(100) default NULL, `website` varchar(100) default NULL, `fax` varchar(30) default NULL, `employees` int(10) default '0', `emailoptout` char(3) default '0', `notify_owner` char(3) default '0', PRIMARY KEY (`accountid`), KEY `account_type` (`account_type`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1

---

serveur linux sans problème:

Citation:

---

CREATE TABLE `vtiger_account` ( `accountid` int(19) NOT NULL default '0', `accountname` varchar(100) NOT NULL default '', `parentid` int(19) default '0', `account_type` varchar(200) default NULL, `industry` varchar(200) default NULL, `annualrevenue` int(19) default '0', `rating` varchar(200) default NULL, `ownership` varchar(50) default NULL, `siccode` varchar(50) default NULL, `tickersymbol` varchar(30) default NULL, `phone` varchar(30) default NULL, `otherphone` varchar(30) default NULL, `email1` varchar(100) default NULL, `email2` varchar(100) default NULL, `website` varchar(100) default NULL, `fax` varchar(30) default NULL, `employees` int(10) default '0', `emailoptout` char(3) default '0', `notify_owner` char(3) default '0', PRIMARY KEY (`accountid`), KEY `account_type` (`account_type`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1

---

si jamais quelqu'un à une idée de génie je suis toujours preneur.

voici deux tests à faire :

1/ peux-tu passer cette requête sur chacun des deux serveurs :

Code:

---

1 2 3 4

SELECT user, host FROM mysql.user WHERE user in ('root', 'vtiger') ;

---

2/ peux-tu renommer ta table sur le serveur de prod, juste pour provoquer une erreur et savoir si le message d'erreur apparaît ?

sur le serveur de prod:

Citation:

---

"root %"
"vtiger %"
"root 127.0.0.1"
"vtiger 192.168.0.1"
"root localhost"
"vtiger localhost"

---

sur le serveur linux

Citation:

---

"root %"
"root localhost"
"root servlinux1"

---

Voilà l'erreur que j'obtient si je modifie le nom de l'une des tables qui pose problème:

Citation:

---

Fatal error: Uncaught exception 'Exception' with message 'result is not an object' in C:\DiaWeb\vtigercrm\include\database\PearDatabase.php:590 Stack trace: #0 C:\DiaWeb\vtigercrm\modules\Accounts\ListView.php(202): PearDatabase->query_result(false, 0, 'count') #1 C:\DiaWeb\vtigercrm\modules\Accounts\index.php(53): include('C:\DiaWeb\vtige...') #2 C:\DiaWeb\vtigercrm\index.php(641): include('C:\DiaWeb\vtige...') #3 {main} thrown in C:\DiaWeb\vtigercrm\include\database\PearDatabase.php on line 590

---

OK... explorons la piste du problème de droits...

à tester sur ton serveur de prod :

Code:

---

1 2 3 4 5 6

show grants for root@'%' ; show grants for vtiger@'%' ; show grants for root@'127.0.0.1' ; show grants for vtiger@'192.168.0.1' ; show grants for root@'localhost' ; show grants for vtiger@'localhost' ;

---

192.168.0.1 est-il ton serveur MySQL ou ton serveur de prod ?

à tester sur ton serveur linux :

Code:

---

1 2 3

show grants for root@'%' ; show grants for root@'localhost' ; show grants for root@'servlinux1' ;

---

Sur le serveur de prod dont l'IP est bien 192.168.0.1

Citation:

---

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY PASSWORD '*E356DEAD9648CFFB24DCD490065E032411731693' WITH GRANT OPTION

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `vtigercrm504`.* TO 'root'@'%' WITH GRANT OPTION

---

sur le serveur linux

Citation:

---

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION

---

Là tu me réponds pour root@'%'. Or, il est masqué par l'existence d'utilisateurs plus spécifiques : root@'192.168.0.1' et root@localhost (cf FAQ http://mysql.developpez.com/faq/?pag...B_choix_compte).

Tu peux vérifier les grants de ces utilisateurs, ou bien les supprimer purement et simplement.

bon j'ai supprimé les autre utilisateurs sur le serveur de prod j'ai conservé que @%

quand je fait le grant de root ca donne celà

Citation:

---

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY PASSWORD '*E356DEAD9648CFFB24DCD490065E032411731693' WITH GRANT OPTION
GRANT ALL PRIVILEGES ON `mysql`.* TO 'root'@'%' WITH GRANT OPTION
GRANT ALL PRIVILEGES ON `test`.* TO 'root'@'%' WITH GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `vtigercrm504`.* TO 'root'@'%' WITH GRANT OPTION
GRANT ALL PRIVILEGES ON `information_schema`.* TO 'root'@'%' WITH GRANT OPTION

---

et pour mon user vtiger

Citation:

---

GRANT USAGE ON *.* TO 'vtiger'@'%' IDENTIFIED BY PASSWORD '*61D9A2C1961DD18F9216CF863446200A68DB1098' WITH MAX_QUERIES_PER_HOUR 10000 MAX_UPDATES_PER_HOUR 10000 MAX_CONNECTIONS_PER_HOUR 10000 MAX_USER_CONNECTIONS 10000
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `vtigercrm504`.* TO 'vtiger'@'%' WITH GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `test`.* TO 'vtiger'@'%' WITH GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `mysql`.* TO 'vtiger'@'%' WITH GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `information_schema`.* TO 'vtiger'@'%' WITH GRANT OPTION

---

Et ça marche maintenant que tu as supprimés les comptes @localhost et @'192.168.0.1' ?

non toujours le meme problème, celà n'a rien changé, j'ai essayer avec le user root et vtiger meme combat.

Ce qui est chiant, c'est de ne pas avoir le message d'erreur SQL...

Est-ce que SHOW ERRORS sur le serveur de prod te donne quelque chose ?

non le show errors ne donne rien, d'ailleurs si je me connecte avec sqlyog sur le serveur pour faire les update en ligne de code, il fonctionne, donc mes user ont les droits pour le faire, mais pourquoi celà ne marche pas à partir du PHP, mystère

faut rentrer dans le code PHP...

oui, mais pourquoi ca marche sur un serveur et pas l'autre?
le code php reste le meme, c'est juste le serveur qui change...

Citation:

---

Envoyé par jrcouasnon

oui, mais pourquoi ca marche sur un serveur et pas l'autre?
le code php reste le meme, c'est juste le serveur qui change...

---

Impossible à savoir sans au minimum faire ressortir les erreurs SQL, et pour cela il faut rentrer dans le PHP.

comme là ca va aller largement au delà de mes compétences, je te remercie pour ton aide et le temps passé.
Je vais transférer ma base sur mon serveurlinux de facon definitive et comme celà on aura un petit temps de latence supplémentaire mais au moins tout va marcher.

Encore merci a toi.