MySQL-запрос работает в NaviCat, но не в SugarCRM
Если вам понадобится дополнительная информация, которая поможет вам решить проблему, просто дайте мне знать.
Я использую SugarCRM 6.5.20 CE
У меня есть логическая ловушка, которая запускается для пользовательского модуля, и когда я иду, чтобы проверить журнал, запрос показывает время выполнения и, кажется, работает просто отлично, но база данных фактически не обновляется.
Я взял этот же запрос прямо из файла sugarcrm.log, а затем запустил запрос в Navicat, и … он обновился без проблем.
Я уже пробовала
- Some / None / All Backticks вокруг имен столбцов / таблиц
- Убедиться, что я не использовал зарезервированные слова
Так что на данный момент я хочу объяснить это проблемой версии MySQL, возможно. Я использую MySQL версии 5.5.49-cll.
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: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
Решение
Мой предыдущий ответ появился работать, но на самом деле не работал.
Реальное решение было связано с использованием after_save логический хук, по сравнению с использованием before_save логический крючок
Чего я не знал, так это того, что в before_save Логические перехваты, когда вы запускаете SQL-запрос, он возвращается к нему и снова запускает оператор Update, но на этот раз с пустыми значениями, где я пытался обновить значения.
Меняя это на after_save сразу решил вопрос.
Другие решения
Других решений пока нет …