[ts-gen] Blowup in Paper Account due to failed reception of OrderStatus 3/3/6 Filled

Nils Gebhardt mail at ngebhardt.de
Fri Sep 25 01:34:36 EDT 2009

Hi Ken, 

On Fri, 2009-09-25 at 09:06 +0900, Ken Feng wrote:
> Hi Nils,
> I did read your thread with interest last night before my mind turned  
> into mush.  I think your problem may be related to what happened to  
> me, but maybe not (more on this later).
> Assuming that we are having the same problem, shouldn't an INSERT  
> IGNORE just replace the old row with the new row, even if there were a  
> unique key constraint?  I only care about (and generate reports on)  
> the newest entries in OrderStatus.
> Just to make things clear, in the 090904 code,
> 1. Is there an INSERT IGNORE for OrderStatus?
> 2. Is it true that in your case, you saw an entry in the Log, but not  
> in OrderStatus?

1. probably yes - I used 090915
2. yes

> If 1. is true, shouldn't we get the new row, while the old row gets  
> destroyed?  Which would be ok in my case since I do a query to get the  
> newest row according to the time field for a given perm/client_id.

As I understand, the new row is ignored. From 

/begin quote/
If you use the IGNORE keyword, errors that occur while executing the
INSERT statement are treated as warnings instead. For example, without
IGNORE, a row that duplicates an existing UNIQUE index or PRIMARY KEY
value in the table causes a duplicate-key error and the statement is
aborted. With IGNORE, the row still is not inserted, but no error is
/end quote/

Actually I also would find an update preferable. This probably would
require a Syntax as ON DUPLICATE KEY UPDATE. 

> If 2. is true, I am also very interested in the resolution of your  
> problem, but it may be different from mine.

currently I stick to log/ShimText for the fills, using the order_tag
identifier. But I also am rather looking for a solution than having

> AFAIK, in my situation, the change in status didn't make it into the  
> Log or the OrderStatus.
If it i not in the Log, it really seems to be a problem - it would mean
the message was never sended, right? 



More information about the ts-general mailing list