Partial UPDATE execution? Perl DBI MySQL

------=_Part_2932_5269741.1211491647499
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Has anyone ever seen a partial execution of an UPDATE statement?

I'm using Perl DBI to update a table in MySQL.

The strangest thing to me is that a varchar(35) field which holds a custom
date/time format was updated correctly, but other tinyint(1) fields were not
set correctly, and 1 of 3 text fields which were supposed to add the new
"log" to existing logs in the 3 fields did not appear in the 1 field, but
did in the other 2.

I found the query in the mysql query log file and some of the text had
newlines. So I thought the query may have failed at this point, BUT when
manually executing the query in phpMyAdmin, it executed fine. I thought the
whole query would fail due to possibly not escaping some characters. BUT,
like I said before, even this logic is incorrect because some fields were
updated before my manual attempt at testing the query.

The only similar behavior I've seen is using C/C++ with printf and sometimes
you need to add a "flush" statement so the text really prints.

Basically for 5 years, this script has used the following sequence (prepare,
execute, finish). But there have been recent changes to the script. Only
one record is showing this strange behavior (but it most likely touches code
that other records do not).

After the successful manual execution of the statement, the 3 text fields do
not verify my claim that 1 in 3 had previously failed. BUT the custom
date/time field was confirmed by a few people to have been updated (when
other fields were not), so I may not be going crazy.

This is a single UPDATE statement. No transactions are involved.

TIA

------=_Part_2932_5269741.1211491647499--

Re: Partial UPDATE execution? Perl DBI MySQL

------=_Part_14349_7687312.1211494054111
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, May 22, 2008 at 5:27 PM, Dee Ayy wrote:

> Has anyone ever seen a partial execution of an UPDATE statement?
>
> I'm using Perl DBI to update a table in MySQL.
>
> The strangest thing to me is that a varchar(35) field which holds a custom
> date/time format was updated correctly, but other tinyint(1) fields were
> not
> set correctly, and 1 of 3 text fields which were supposed to add the new
> "log" to existing logs in the 3 fields did not appear in the 1 field, but
> did in the other 2.
>
> I found the query in the mysql query log file and some of the text had
> newlines. So I thought the query may have failed at this point, BUT when
> manually executing the query in phpMyAdmin, it executed fine. I thought
> the
> whole query would fail due to possibly not escaping some characters. BUT,
> like I said before, even this logic is incorrect because some fields were
> updated before my manual attempt at testing the query.
>
> The only similar behavior I've seen is using C/C++ with printf and
> sometimes
> you need to add a "flush" statement so the text really prints.
>
> Basically for 5 years, this script has used the following sequence
> (prepare,
> execute, finish). But there have been recent changes to the script. Only
> one record is showing this strange behavior (but it most likely touches
> code
> that other records do not).
>
> After the successful manual execution of the statement, the 3 text fields
> do
> not verify my claim that 1 in 3 had previously failed. BUT the custom
> date/time field was confirmed by a few people to have been updated (when
> other fields were not), so I may not be going crazy.
>
> This is a single UPDATE statement. No transactions are involved.
>
> TIA
>

If its one record, could you just have corrupted data on that record? Based
on your description, perhaps thats all it is. Try cleaning the record and
seeing if that fixes the problem.

--

Bastien

Cat, the other other white meat

------=_Part_14349_7687312.1211494054111--