-----Original Message----- From: Martijn Pieters [mailto:mj@zope.com]
Sounds like you are bitten by the fact that MySQL is by default not transactional; my guess is that the request is conflicting somewhere, or maybe you mail server is raising an error, and the transaction is aborted or retried (the latter in case of a conflict). MySQL will not roll back the transaction at that moment, while the email hasn't been sent yet.
I figured maybe something like that. Looking at the timestamp of the last two empty MySQL records, they correspond conspicuously with the session logging information I just implemented to debug my disappearing carts: 2001-10-02T21:01:19 INFO(0) Session START new token pyid 147139568 sid 19270093Az-6bVJDKrM ip 65.100.181.192 2001-10-02T21:01:19 INFO(0) Session CALL (add [get]) new token pyid 142775672 sid 19270093Az-6bVJDKrM len 0 cart None 2001-10-02T21:01:19 INFO(0) Session CALL (add [set]) new token pyid 147428688 sid 19270093Az-6bVJDKrM len 0 cart None 2001-10-02T21:01:20 INFO(0) Session CALL (Items [get]) pyid 150552544 sid 19270093Az-6bVJDKrM len 1 cart 1 2001-10-02T21:02:17 INFO(0) Session CALL (checkout [get]) pyid 147444240 sid 19270093Az-6bVJDKrM len 1 cart 1 2001-10-02T21:04:20 INFO(0) Session CALL (gatherCheckout [set]) pyid 147436552 sid 19270093Az-6bVJDKrM len 1 cart 1 2001-10-02T21:04:21 INFO(0) Session CALL (verify [get]) pyid 145239704 sid 19270093Az-6bVJDKrM len 2 cart 1 2001-10-02T21:04:21 INFO(0) Session CALL (Items [get]) pyid 145921552 sid 19270093Az-6bVJDKrM len 2 cart 1 2001-10-02T21:04:49 INFO(0) Session CALL (Items [get]) pyid 145921552 sid 19270093Az-6bVJDKrM len 2 cart 1 2001-10-02T21:04:49 INFO(0) Session CALL (Items [get]) pyid 146880720 sid 19270093Az-6bVJDKrM len 2 cart 1 2001-10-02T21:04:50 INFO(0) Session CALL (sendOrder [invalidate]) pyid 145792704 sid 19270093Az-6bVJDKrM len 2 cart 1 2001-10-02T21:04:50 INFO(0) Session END sid 19270093Az-6bVJDKrM 2001-10-02T21:05:09 INFO(0) Session START pyid 152529584 sid 19270093Az-6bVJDKrM ip 65.100.181.192 2001-10-02T21:05:13 INFO(0) Session START pyid 148488176 sid 19270093Az-6bVJDKrM ip 65.100.181.192 It's the last two entries that have the same timestamp as two empty records in the MySQL database. There are no conflict log entires in the stupid log. The 'Session END' entry above has the same timestamp as the successfully stored and e-mailed order. The only thing the 'sendOrder' python script does after invalidate() is RESPONSE.redirect to another page. It seems that if it made it that far, a simple RESPONSE.redirect wouldn't cause any conflicts. Does this make sense? Is there a more reliable way to produce a sequence of numbers with less (zero?) risk of skipping or duplicate numbers? _______________________ Ron Bickers Logic Etc, Inc.