отловить не исполняемый запрос

[bars80081]

ситуация - полтергейст

при совершении определённой операции на пхп у меня в коде друг за другом выполняется несколько запросов к БД mysql. в частности в одном куске друг за другом идут запросы:
update ... table1 ...
insert ... table2 ...
update .. table1 ...
insert ... table2 ...
каждый запрос отдельно выполняется через mysql_query(), значения полей вычисляются на пхп

проблема заключается в том, что запросы insert к table2 проходят, а запросы update к table1 нет. ситуация дикая, так как данный код регистрирует проведение финансовых транзакций. вначале идёт обновление баланса (update ... table1) следом регистрация транзакции (insert ... table2) для контроля. в итоге получается, что контроль регистрирует проведение транзакции, а баланс не изменяется
никаких блокировок таблицы не применяю и никто параллельно не применяет

логирование на неуспешный update ничего не показало. запрос завершается нормально, система не валится. к сожалению (для тестирования, но к счастью для реализации) эта хрень случается не часто. сейчас ужесточу логирование и поставлю сохранение количества обновлённых строк, но пока это покажет какие-либо результаты - трудно сказать.

соответственно, хочу спросить в чём может быть причина? так как всегда полагал на то, что если уж я делаю запрос и система не валится, а результат возвращается успешным, то изменения произошли. а теперь нет доверия всему

 

[Фанат]

Если данные не изменились, то
- они уже были те же самые, что и в запросе на апдейт
- не найдено строк по условию WHERE
- была откачена транзакция

 

[bars80081]

Если данные не изменились, то
- они уже были те же самые, что и в запросе на апдейт
- не найдено строк по условию WHERE
- была откачена транзакция

1. проблема выявилась только из-за того, что не вставлялись новые значения, отличные от предыдущих
2. в условии WHERE стоит id записи, а записи там вообще никогда не удаляются
3. не совсем понял

вот сейчас разместил новое логирование. в штатном режиме всё проходит нормально:
[2013.09.19_16:43.39][953][payer_deposit][350][2465958.10;2476208.1;19550;9300;891;1]
[2013.09.19_16:43.39][953][payer_deposit][478][52162.47;2537670.57;53112.47;2538620.57;891;1]
[2013.09.19_16:43.39][953][payer_deposit][529][53112.47;2538620.57;53366.47;2538874.57;891;1]

где запись образуется следующим образом

		$num = mysql_affected_rows();
		$param = array($field1_old, $field1_new, $field2_old, $field2_new, $account_id, $num);
		$s = implode(';', $param);
		$str = "[$time][$user][$class][$line][$s]\n";

то есть в трёх местах запросы UPDATE к таблице прошли успешно (смотрю изменение - реально успешно).

пока система даст сбой - пройдёт возможно месяц, поэтому спрашиваю на теоретическими причинами лажи

что значит "была откачена транзакция"? я сам лично ничего в обратку не делаю

 

[Фанат]

Объяснять мне про id, которые никогда не удаляются - не надо. Мне это не интересно.
ты спросил,

в чём может быть причина?

я ответил.
если ты считаешь, что все условия выполняются - ну, значит и запись проходит

что значит "была откачена транзакция"?

rollback

 

[bars80081]

rollback

слово "транзакции" я применил чисто в финансовом плане. никаких mysql-конструкций связанных с транзакциями у меня нет. используются только SELECT, INSERT и UPDATE. так что гарантированно нигде RALLBACK не используется

 

[Breeze]

bars80081

ты знаешь что такое affected rows?
финансы без транзакций, страшно же

 

[bars80081]

ты знаешь что такое affected rows?

только сейчас поставил в проверку

финансы без транзакций, страшно же

ну, не то чтобы страшно. как всегда разработка начиналась с небольшого набора страничек, а в итоге пришли к продажному конвейеру. соответственно, знаний о том "как надо делать" не имелось и не имеется. решается по факту столкновения.
вот обрисовалась эта проблема, как найду причину и решение, так и реализую

 

[Breeze]

только сейчас поставил в проверку


ну, не то чтобы страшно. как всегда разработка начиналась с небольшого набора страничек, а в итоге пришли к продажному конвейеру. соответственно, знаний о том "как надо делать" не имелось и не имеется. решается по факту столкновения.
вот обрисовалась эта проблема, как найду причину и решение, так и реализую

вот-вот, ее не для логирования все-таки надо юзать =)
в финансах имхо на любой неправильный чих надо принимать меры, а тут как раз настоящие транзакции с коммитами и роллбеками, исключения в помощь

 

[Dez]

надо смотреть код, где ты update делаешь.
Т.к. если после update ты в лог кидаешь mysql_affected_rows , которые равны 1, то изменение должно было физически произойти. (Нужно смотреть как ты вызываешь mysql_connect, т.к. данное поведение могло тут быть переопределено)

 

[bars80081]

если после update ты в лог кидаешь mysql_affected_rows , которые равны 1, то изменение должно было физически произойти

пока что новой ошибки не произошло. жду

Нужно смотреть как ты вызываешь mysql_connect, т.к. данное поведение могло тут быть переопределено

у меня коннект к БД идёт всего один раз на старте. причём, раз скрипт добрался до стадии проведения работы с этими таблицами, значит перед этим работа с БД была успешной, как на выборку, так и на запросы INSERT и UPDATE