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

[Ken Feng]

On Sep 25, 2009, at 2:34 PM, Nils Gebhardt wrote:
>
>>
>> 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
> http://dev.mysql.com/doc/refman/5.1/en/insert.html
>
> /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
> issued.
> /end quote/
>
> Actually I also would find an update preferable. This probably would
> require a Syntax as ON DUPLICATE KEY UPDATE.

Wow, I am surprised to learn of this - perhaps your solution or a  
REPLACE INTO would work.
Either way, having the newest line dropped for whatever reason would  
be quite troubling, indeed.

>> 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
> one.

For now, I am doing as you do, but I am going to add an automated  
process to pull down trades from the TWS GUI for additional  
confirmation.  My paper account blew up because I had Submitted (not  
filled) orders in OrderStatus, but were shown to be filled in the TWS  
GUI.

The system continued to generate orders, trying to push the positions  
into the desired state, when it was already there and far, far beyond...

>> 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?

I agree that there is nothing the Shim can do, in this case.
Nonetheless, I will have to find ways to code around this issue.

- Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.trading-shim.org/pipermail/ts-general/attachments/20090925/51907d60/attachment.html