Help with BA's order of doing things needed

[Mitch]

This is a question that only Gary may be able to answer, but anyone feel free to jump in

I was wondering what the exact order was that BA did things when exporting to Excel.

I know that it sends the main price info first (columns A to M) then sends the bet info 1 line at a time, so if there are 8 runners then BA sends 9 lots of data for each refresh.

What I don't know is when it reads cols N to P for placing and cancelling bets. Is it 1 row at a time or all together, and when in amongst sending data to Excel does it happen.

The reason I ask is that I have a spreadsheet that has a cancel routine as part of it and occasionally (maybe 1 in 30) it reads the cancel as successful but the bet was completely taken. I've gone through my code time and again and can't see why it would happen so this is my last resort.

The routine is triggered each refresh of BA (only when the main data is changed) and the test to see if the cancel has been successful is "BetRef=empty and MatchedStake=0"

Any help appreciated.

[Ian]

Mitch - somewhere in the threads from the Betfair forum I asked the same question and Gary did reply as to what the sequence was then. This may have changed since though, of course. I can tell you that if you lay a big field using excel triggers, say, all the 120 players in golf tournament, then these appear to go altogether - by that, I mean its not one line at each refresh or anything like that.

[Mitch]

Yeah, I don't think it will have anything to do with it. The only thing I could think of was if it pasted some data, read some back, then my macro changed some cells and it read them again. I still don't know how that would cause my problem, but I'm at the 'clutching at straws' stage now.

Thanks for the input Ian.

[nanook]

Mitch,

Looks like you've run into the problem I described in the thread "how to know when a bet has been cancelled?"
I am not alone!

I suspect that when a cancel is triggered and the bet ref cell clears, the cancel trigger is programmed to always clear this cell and not as a response to the bet actually cancelling in Betfair. In some cases the bet ref will clear, then the bet will actually match but the matched stake won't update to reflect this. If you re-read the thread I referenced above, it may be helpful now that you've actually encountered the problem.

In the end, I worked out a bandaid solution:

Trigger a cancel
Monitor the bet ref cell for X seconds (I used 5 - may work with less)
If the bet ref clears within this period, replace it
After the monitoring period then check the matched stake. If its zero, its safe to conclude the bet is cancelled.

I have not used this in a while but it worked with no problems at the time. It seems that when the bet ref is blank, the matched stake won't update even though the bet has actually matched and replacing the bet ref allows this update to occur.

Hope this helps.

[GaryRussell]

I shall give a definitive answer this evening. I've got to go through the code and check exactly how it's working.

This is a question that only Gary may be able to answer, but anyone feel free to jump in

I was wondering what the exact order was that BA did things when exporting to Excel.

I know that it sends the main price info first (columns A to M) then sends the bet info 1 line at a time, so if there are 8 runners then BA sends 9 lots of data for each refresh.

What I don't know is when it reads cols N to P for placing and cancelling bets. Is it 1 row at a time or all together, and when in amongst sending data to Excel does it happen.

The reason I ask is that I have a spreadsheet that has a cancel routine as part of it and occasionally (maybe 1 in 30) it reads the cancel as successful but the bet was completely taken. I've gone through my code time and again and can't see why it would happen so this is my last resort.

The routine is triggered each refresh of BA (only when the main data is changed) and the test to see if the cancel has been successful is "BetRef=empty and MatchedStake=0"

Any help appreciated.

[GaryRussell]

The program processes CANCEL requests one row at a time after updating the prices. It immediately checks the response from the server and clears the bet ref if successful. I found a potential problem in the way it checked the response. If the response was empty (ie. server error which we have been suffering lately) then it would treat the bet as cancelled successfully. I have changed it to only clear the bet ref if there is a proper response. I hope this solves your problem, if not please let me know. This fix is in version 0.99m

This is a question that only Gary may be able to answer, but anyone feel free to jump in

I was wondering what the exact order was that BA did things when exporting to Excel.

I know that it sends the main price info first (columns A to M) then sends the bet info 1 line at a time, so if there are 8 runners then BA sends 9 lots of data for each refresh.

What I don't know is when it reads cols N to P for placing and cancelling bets. Is it 1 row at a time or all together, and when in amongst sending data to Excel does it happen.

The reason I ask is that I have a spreadsheet that has a cancel routine as part of it and occasionally (maybe 1 in 30) it reads the cancel as successful but the bet was completely taken. I've gone through my code time and again and can't see why it would happen so this is my last resort.

The routine is triggered each refresh of BA (only when the main data is changed) and the test to see if the cancel has been successful is "BetRef=empty and MatchedStake=0"

Any help appreciated.

[Mitch]

Thanks Gary, that sounds like just the sort of thing that would have confused my code. I'll play with it tonight and let you know if it happens.

nonook - as far as I know the bet ref is supposed to clear whether a cancel request has been successful or not, except when the bet is completely matched in which case it stays there. If I'm right then the bet ref wouldn't clear itself until the response came back that the request was successful.

[nanook]

Did this get resolved? If its still a live issue, I can backtrack to when I was having a problem, remove the fix I was using and see if the problem still occurs.