Thanks catfloppo, you needn't worry as most of my bets will be elsewhere.

I think Joe's way is the way to go but it means having to note the betid of every bet you place so you're only sending unmatched betid's in the betid array (in that case I'd probably be sending at most 1 betid per runner which would be way short of the 200). A call that would send back a summary of matched bets for each runner (potential profit and stake) along with unmatched bets in one call would've saved a lot of coding.

Another thing that really shocked me was that you're unable to specify you're not betting ir when submitting bets (to combat the bet just being sent as the market goes in play). It's not even like you can call up the market status right after and cancel immediately as you're stuck behind the clock. Is that a bertie bonus for mugging crews or something?

Paul, you, pathetic little c0ck, what I saw was that you had a little fit, and starting abusing me as well as some other forumites.

By the way, have you seen this video?

http://www.youtube.com/watch?v=Vwigmktix2Y

Not much you can do to avoid hitting the market just as it goes inplay Feck, I do a getprices call before submitting any bet for latest prices and just use the inplay flag in the response to avoid betting inplay that's probably the best you can do to avoid it.

Only other thing I'd suggest is you could consider including a BSP limit bet in each bet array. Usually if a bet is rejected in a placebet request it rejects all the bets in that request so a BSP bet placed after the off would be rejected. By sending a BSP limit bet you'd be able to send a valid bet that had no chance of being matched i.e. lay £10 liability with a max price of 1.1 on an outsider.

*I take it I can find what lays have been automatically cancelled

Forget those last 3 posts regarding cancelled bets. I'm hoping I've found a way of processing a race without having to store betId's or worry about withdrawals and RF's.

The information I need is

a) My stakes matched so far and average odds obtained on each individual runner (after any RF's).
b) My current unmatched bets in system.
c) The current state of the market (i.e. odds and stakes on offer).

For place markets a) can be obtained simply by calling getMarketProfitAndLoss. For win markets I'm thinking I'll call getCurrentBets for the appropriate MarketID with betStatus M and total the matchedSize and profitAndLoss fields by selectionID. I'm not using getMUBets for this because of the returned records limit and the fact it could theoretically return 200 records for one £2 matched bet (I require only a summary on matched bets).

I'll get b) by calling getMUBets with betStatus U. This will only return 1 record per betId and, as I don't expect to have any more than 2 or 3 unmatched bets per runner, this will be well within the 200 max record limit.

[Note: I could skip b) altogether if getCurrentBets accepted a betStatus of MU in the request but Contrarian said it didn't with marketID=0 and the documentation says you must choose M or U if a marketID is supplied.]

For c) I'll call getMarketPricesCompressed.

The information from a,b & c will allow me to cancel any unwanted bets, and update / add to existing unmatched bets based on my opinion where the value is. After that I can then move on to process the next market (or re-process that one) without the need to store or track anything.

As I've yet to try any of this I may be misunderstanding the less than reliable documentation so if anyone sees any pitfalls (beyond the obvious changes between calls) I'd welcome your comments.

I think he was merely satirising your apparent inability to recall any of a threads preceding posts.  Your questions do appear, at least on occasions, much like the blinking man in the video, as if you have only just joined the forums.  Which actually you usually have

Does getAccountStatement work properly. Regardless of what I set Req->startDate to (even today's date) I get the same 52 records returned that belong to over a month ago.

GetAccountStatement *Req = new GetAccountStatementRequest;
Req->header = new NS_BFExchangeService::APIRequestHeader;
Req->header->sessionToken = SessionToken;

int FetchSize=20000;
Req->recordCount=FetchSize;
Req->startDate=new TXSDateTime;
Req->startDate->AsDateTime=TDateTime().CurrentDate();
Req->endDate=new TXSDateTime;
Req->endDate->AsDateTime=TDateTime().CurrentDate();
Req->itemsIncluded=AccountStatementIncludeEnum::EXCHANGE;


While I'm at it, if anyone uses c++, can you tell me why I've got to use new to create the startDate and endDate request variables whereas the Request constructers for all other api functions seems to take care of creating / destroying internal variables.

Thanks for the reply JL. The FetchSize=20000 was just part of a test but there's no mention of a limit in the documentation. I wasn't expecting any more than 52 records (that's all my activity within the last 3 months), I was expecting zero as I set the startDate to today and my last activity was around a month ago.

PS You're only allowed a call a minute with the free API so if you don't get all the records in a oner you have to wait a minute before the second call or it returns API_ERROR.

Yesterday was the first chance I had to test the GetAccountStatement function. As subversion kindly pointed out setting ItemsIncluded to ALL means the startDate and endDate properties are ignored BUT, as I found out yesterday, if I set ItemsIncluded to ALL then NO_RESULTS is returned. I had to set it to EXCHANGE to get yesterdays bets.

Feck here BTW.