La requête MySQL fonctionne dans NaviCat mais pas dans SugarCRM

Question

Si des informations supplémentaires sont nécessaires pour vous aider à résoudre le problème, faites le moi savoir.

Je suis en cours d'exécution SugarCRM 6.5.20 CE

J'ai un crochet logique qui se déclenche pour un module personnalisé et quand je vais vérifier le journal, la requête affiche un temps d'exécution et semble fonctionner très bien , mais la base de données n'est pas réellement mise à jour.

J'ai extrait cette même requête du fichier sugarcrm.log puis j'ai exécuté la requête dans Navicat, et ... elle a été mise à jour sans problème.

J'ai déjà essayé

• Certains/Aucune/Tous les noms autour de la colonne contre-apostrophes/Table
• Se assurer que je n'utilisais pas des mots réservés

donc à ce stade je Je veux craie jusqu'à un problème de version MySQL éventuellement. Je cours MySQL version 5.5.49-cll. Est-ce que quelqu'un pourrait aider à penser pourquoi il ne lancerait pas d'erreur mais ne mettrait pas réellement à jour la base de données?

Voici également le fichier journal où il a tiré:

Wed Jun 1 20:30:06 2016 [26589][1][INFO] Query:UPDATE my_database.p_policies_cstm 
      LEFT OUTER JOIN r_raises_p_policies_1_c ON p_policies_cstm.id_c = r_raises_p_policies_1_c.r_raises_p_policies_1p_policies_idb 
      LEFT OUTER JOIN r_raises_cstm ON r_raises_cstm.id_c = r_raises_p_policies_1_c.r_raises_p_policies_1r_raises_ida 
      SET factor_c = '1.00', client_ppp_c = '1,529,987.76' 
      WHERE r_raises_p_policies_1_c.r_raises_p_policies_1p_policies_idb = 'e1570120-56e0-5d75-8ab7-574f2ef83a5b' 
Wed Jun 1 20:30:06 2016 [26589][1][INFO] Query Execution Time:0.000363111495972 
Wed Jun 1 20:30:06 2016 [26589][1][INFO] Get One: |SELECT id_c FROM p_policies_cstm WHERE id_c = 'e1570120-56e0-5d75-8ab7-574f2ef83a5b'| 
Wed Jun 1 20:30:06 2016 [26589][1][DEBUG] Limit Query:SELECT id_c FROM p_policies_cstm WHERE id_c = 'e1570120-56e0-5d75-8ab7-574f2ef83a5b' Start: 0 count: 1 
Wed Jun 1 20:30:06 2016 [26589][1][INFO] Query:SELECT id_c FROM p_policies_cstm WHERE id_c = 'e1570120-56e0-5d75-8ab7-574f2ef83a5b' LIMIT 0,1 
Wed Jun 1 20:30:06 2016 [26589][1][INFO] Query Execution Time:0.000181913375854 

Answer 1

Ma réponse précédente est apparu au travail, mais n'a pas fait.

La vraie solution a dû faire avec l'utilisation after_save crochet logique, par rapport à l'aide d'un crochet logique before_save. Ce que je ne savais pas, c'est que dans before_save crochets logiques, lorsque vous lancez une requête SQL, il revenait dessus et renvoyait une instruction de mise à jour, mais cette fois avec des valeurs vides où j'essayais de mettre à jour les valeurs .

La modification à un after_save a immédiatement résolu le problème.