FD Racing?

[vegasone]

Well, if you use your own software you can convert to whatever code you want. If you have everything in a database then can write a little software code to change track code before or after you import data. A pain for sure otherwise. I always keep the original code going.

[ranchwest]

Originally Posted by vegasone

Well, if you use your own software you can convert to whatever code you want. If you have everything in a database then can write a little software code to change track code before or after you import data. A pain for sure otherwise. I always keep the original code going.

But you have to be on top of it at the beginning of the new code or the change can only be done retroactively. Meanwhile, you're not looking at what you think you are.

[MJC922]

Originally Posted by ranchwest

But you have to be on top of it at the beginning of the new code or the change can only be done retroactively. Meanwhile, you're not looking at what you think you are.

Exactly, this is the key and it's why any changes like this are critically important to be communicated. When I auto-download charts from Trackmaster every night to create product for subscribers I'm downloading a filename which has the track abbreviation as part of the filename. So for Fairmount Park that was FP. When it changed to FAN there were a whole bunch of charts that didn't get downloaded, like for several months this went on.

Subsequently horses running back out of those races were missing entire races in the PPs of my product. I had to scramble to get Trackmaster to send me the back charts and reprocess a whole bunch of stuff at once. They're supposed to let me know about changes like these but now per CJ I'm hearing about this BAQ change and I'm not hearing it from Trackmaster. smh

It gets my paranoia going about my customers calling up to report missing data and then what happens with those customers. Oh I'm pretty sure I know what happens...

This is the site I check every year to add abbreviations to the chart downloader:

https://www.equibase.com/products/racedates.cfm?SAP=TN

Apparently I'm going to have to do vlookups on that webpage every month from now on. Checking it annually at the start of a new year when logically race dates and abbreviations should already be 'locked in' doesn't cut it anymore, especially when they say they'll let me know about changes and I hear nothing. The only one I can depend upon to actually communicate this out is CJ so thank you CJ.

[Tom]

Originally Posted by ranchwest

I think that was the way Oak Tree was handled, too. Anything to complicate handicapping and recognize the money interests.

The decision to totally screw things up for evertone for no reason was mase by


MEQuibase......Morons @ Equibase!

[eqitec]

Re: Paper Cuts: I've documented that Equibase is not sending the code to BRIS for BRIS data files for synthetics along with workouts at GP that occur over its new synthetic surface. I've not found a way to tell the difference between a workout over dirt or synthetic at GP.

I've forwarded my documentation to BRIS months ago. While BRIS has been very responsive, they have not been able to solve the problem.

Does anyone have a contact at Equibase who I can contact to take up the issue?

[ubercapper]

Originally Posted by eqitec

Re: Paper Cuts: I've documented that Equibase is not sending the code to BRIS for BRIS data files for synthetics along with workouts at GP that occur over its new synthetic surface. I've not found a way to tell the difference between a workout over dirt or synthetic at GP.

I've forwarded my documentation to BRIS months ago. While BRIS has been very responsive, they have not been able to solve the problem.

Does anyone have a contact at Equibase who I can contact to take up the issue?

Send me a PM and I'll figure out who to route this to.

[ubercapper]

Tom - your comment is both untrue and unfair. As CJ mentioned previously tracks have the right (via contract) to request changes. I empathize with Jeff, Mike and others who have to code around it but the blame does not lie with Equibase.

[ranchwest]

Originally Posted by ubercapper

Tom - your comment is both untrue and unfair. As CJ mentioned previously tracks have the right (via contract) to request changes. I empathize with Jeff, Mike and others who have to code around it but the blame does not lie with Equibase.

Are you saying that Equibase is bound by a contract, but they are not a party to the contract? How does that work?

[o_crunk]

Originally Posted by ubercapper

Tom - your comment is both untrue and unfair. As CJ mentioned previously tracks have the right (via contract) to request changes. I empathize with Jeff, Mike and others who have to code around it but the blame does not lie with Equibase.

Equibase is the "industry's database". There is no one else to get data from. You guys do not need to change the track_id. It's just a column that only exists in Equibase's world. Without Equibase, there would be no track_id.

I just don't understand how Equibase doesn't see fit to steward their own data correctly. This upcoming "Belmont at Aqueduct" meet is a prime example of poor stewarding. The races will take place at the Belmont facility, at the same distances and surfaces they always have. Are there going to be new track records for 6F dirt races? Are there going to be new jockey records for wins, etc? It's just poor. The races are at Belmont. That specific geographical place is represented by track_id "BEL" in Equibase data. To call that same specific geographical place something else is against data integrity, something that Equibase should steward properly since they are the only place any of us can get this data (and might I add, pay a very high dollar price for).

It's completely ridiculous. Call the meet whatever you want and there are plenty of places to account for that in Equibase's RDS system but this totally absurd to have one 6F dirt race be at BEL and the same exact surface and distance race at the same facility be considered "BAQ". Absurd.

[cj]

Originally Posted by o_crunk

Equibase is the "industry's database". There is no one else to get data from. You guys do not need to change the track_id. It's just a column that only exists in Equibase's world. Without Equibase, there would be no track_id.

I just don't understand how Equibase doesn't see fit to steward their own data correctly. This upcoming "Belmont at Aqueduct" meet is a prime example of poor stewarding. The races will take at the Belmont facility, at the same distances and surfaces they always have. Are there going to be new track records for 6F dirt races? Are there going to be new jockey records for wins, etc? It's just poor. The races are at Belmont. That specific geographical place is represented by track_id "BEL" in Equibase data. To call that same specific geographical place something else is against data integrity, something that Equibase should steward properly since they are the only place any of us can get this data (and might I add, pay a very high dollar price for).

It's completely ridiculous. Call the meet whatever you want and there are plenty of places to account for that in Equibase's RDS system but this totally absurd to have one 6F dirt race be at BEL and the same exact surface and distance race at the same facility be considered "BAQ". Absurd.

Just to be clear, the races are going to take place at Aqueduct. It is during the time of the usual Belmont meet.

[o_crunk]

Originally Posted by cj

Just to be clear, the races are going to take place at Aqueduct. It is during the time of the usual Belmont meet.

Me mixing up something so simple like that shows how stupid the whole thing is. Does anyone care at all? I guarantee you if you polled the 12 people who have to code all their crap to deal with whatever Equibase decided to do differently than last time, every single one of them would say don't change the track code. I don't care what NYRA wants or what the marketing department wants. They don't have to do the work to deliver the product to the people who are paying and actually care and actually bet.

/end rant.

[Tom]

oSo NYRA asked to screw over a good chunk of their customers?

[Jeff P]

Marquis Downs has been closed since 2019, and my understanding is the property has since been sold.

Moosomin D & E leased the existing track for a 10-day meet.

Opening Day is scheduled for tomorrow Saturday Aug 27, 2022.

Sunday Aug 28, 2022 has cancelled due to lack of entries.

Moosomin D & E has tentative plans to build a new track in Saskatoon.

The new track, which might possibly open as early as next year 2023, will be a completely new physical track and facility at a different location and will be given its own new track code at that time.

Be advised Equibase is distributing these current 2022 races under a new track code MMD, named Moosomin D & E Marquis Downs.

Equibase is treating this as a brand new track in all of their database tables.

Even though the track is physically the same as the old Marquis Downs there is no choice but to distribute this 10-day Marquis Downs meet using the new track code MMD and not MD (the old track code for Marquis Downs) because neither I or HDW was given adequate advance warning.

For the 2022 Marquis Downs meet:

All data and result files will bear the new track code MMD.

All running lines and workouts will bear the new track code MMD.

All stat categories such as rider, trainer, post position, horse at the track, etc. will effectively be handled as if tomorrow Saturday Aug 27, 2022 were opening day at a brand new track.

I apologize for the late announcement.

The one saving grace is that very few ADWs ever carried Marquis Downs.

And the one year I am aware of when the signal was actually distributed the pools were tiny.

Note to Ellis and anybody at Equibase who might be reading this:

It is beyond ridiculous that I have to post a message like the above here.

And then a second time on my own JCapper Message Board so that data customers can at least have some idea of what's going on.


-jp

.

[Tom]

Racing to ir's customers. "GET OFF MY LAWN!

[vegasone]

Originally Posted by ranchwest

But you have to be on top of it at the beginning of the new code or the change can only be done retroactively. Meanwhile, you're not looking at what you think you are.

Having been through this early on, I am now notified of any new track codes Before importing any new info, and if I am not lazy at the moment, I will check what is going on so I can make changes to the track code in software.