Closed (fixed)
Project:
e-Commerce
Version:
4.7.x-1.x-dev
Component:
store
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jun 2006 at 00:25 UTC
Updated:
14 Mar 2007 at 07:45 UTC
Jump to comment: Most recent file
Comments
Comment #1
neclimdulI didn't have any trouble and it seemed to have tested fine so this is strange. You are right that we would be comparing a array or object. I don't think there is a need for all that casting though as php will do it for you. There is also a simpler way to get the value from the query as well and I messed up the variable names so I fixed that in the patch since we really should be consistent. Thanks for catching the edge case where this update is applied with no transactions. I didn't consider that.
I'm going to see about updating the handbook that I got the code from so this error doesn't happen elsewhere as well.
Comment #2
plumbley commentedI'm not sure if this is connected, but I suspect that store.install may also fail to change the sequences (db_next_id) key properly if a database prefix is used. Here's why:
In store.install,v 1.20 2006/05/18 12:42:24 we have
but in database.mysql.inc,v 1.53 2006/05/24 20:46:56 we have
so the sequences table should be prefixed, i.e. we should have
$ret[] = update_sql("UPDATE {sequences} SET name = '{ec_transaction}_txnid' WHERE name = '{ec_store_transaction}_txnid'");Patch appended which I hope should fix.
NB this is a guess from inspection of the code only: I don't have an old install of ecommerce so I have not observed this to fail or tested the patch.
Comment #3
wpd commentedI am fairly certain this is a PHP5 specific problem. My test site is running on my local box with PHP5 and it failed. The same update worked fine on PHP4 box.
I agree the casts are not needed as mention in #1 that was debug code, I forgot to remove.
Comment #4
simehousekeeping, assume fixed
Comment #5
(not verified) commented