Question on BRIS Data files

[JustRalph]

Two Questions:

Is there any way to strip a horse completely out of race....via the BRIS .DRF file?

Is there a way to manually alter the BRIS Par numbers ? prior to putting them into another program?

[Mike at A+]

Two Questions:

Is there any way to strip a horse completely out of race....via the BRIS .DRF file?

Is there a way to manually alter the BRIS Par numbers ? prior to putting them into another program?

First question, yes. Each horse in the DRF file is delimited by the line feed character. If you open a DRF file in WordPad, simply find the horse you want to delete, highlight the entire line and press the Delete key. Then save the file.

Second question, I'm assuming you mean the BRIS Speed Ratings. Again, you could use WordPad or any text editor to make the change but finding the right field could be tricky.

I could perform either of the above tasks by writing a simple program so if you have programming skills you could do the same. You'd need to get a record layout for the DRF file which is available on the BRIS website for free.

[JustRalph]

on the second question....the numbers in the upper right hand corner is what I am talking about........ see pic attached.

I would love to be able to adjust those numbers manually in the card by a pre-determined amount........ prior to opening them in equisim.....which is where the snapshot attached.....is taken from. Or maybe replace them with a better set of numbers.........?

I have seen the map of fields on the bris site, but haven't looked at it lately.

How big a job would this be? Any idea ?

[OverlayHunter]

For anyone with programming skills, what you want to accomplish is relatively easy to do with a database and associated program OR Excel with the associated macro OR a program that simply utilizes one or more arrays or similar structures.

Basic process would be:

1. Open the DRF file (probably don't have to do this step for Excel)
2. Load the file into database tables, Excel spreadsheet(s), or arrays
3. Adjust whatever field or cell or row/column you care to
4. Close and rename the original DRF file (you could delete it but renaming is safer)
5. Export to a new delimited file being careful to use the delimiting conventions of the original and give it the original name

There may be a simpler way that I'm not aware of. Raybo and others can probably help you with the Excel option. Others can probably assist with Access, VB, Foxpro, and other programs.

[DJofSD]

Two Questions:

Is there any way to strip a horse completely out of race....via the BRIS .DRF file?

Is there a way to manually alter the BRIS Par numbers ? prior to putting them into another program?
JR, what do you want to do when you say strip it out of the race via the .DRF file?

OK, I see you're using Equism. I don't know about Equism but with the Custom PP generator, if you put the letter "S" into field number 5 of the horse you want to strip from the file, Custom PP generator will treat it as a scratched horse.

[Tom]

on the second question....the numbers in the upper right hand corner is what I am talking about........ see pic attached.

I would love to be able to adjust those numbers manually in the card by a pre-determined amount........ prior to opening them in equisim.....which is where the snapshot attached.....is taken from. Or maybe replace them with a better set of numbers.........?

I have seen the map of fields on the bris site, but haven't looked at it lately.

How big a job would this be? Any idea ?

I think it is fields 214 - 218. The program , I believe, decides which E1 and E2 to use, sprint or route.

[Mike at A+]

on the second question....the numbers in the upper right hand corner is what I am talking about........ see pic attached.

I would love to be able to adjust those numbers manually in the card by a pre-determined amount........ prior to opening them in equisim.....which is where the snapshot attached.....is taken from. Or maybe replace them with a better set of numbers.........?

I have seen the map of fields on the bris site, but haven't looked at it lately.

How big a job would this be? Any idea ?
Fields 214-218 are:

214 2f BRIS Pace Par for level NUMERIC 999 3
215 4f BRIS Pace Par for level NUMERIC 999 3
216 6f BRIS Pace Par for level NUMERIC 999 3
217 BRIS Speed Par for class level NUMERIC 999 3
218 BRIS Late Pace Par for level NUMERIC 999 3

The snapshot you attached shows 4 numbers so which of the above 5 is not represented?

The bigger question is how do you want to change these numbers to "something better"? Is there some formula you wish to use that will apply to every horse in the file with a single click or do you want some utility program that will allow you to scroll through a bunch of screens displaying the numbers for each horse and allow you to manually insert the "better" numbers? Either approach can be taken from a programming standpoint and I could probably bang it out in a day or two. But a few things need to be clarified up front like keeping a backup of the original file, folders where the changed files will go, etc.

[Tom]

The snapshot you attached shows 4 numbers so which of the above 5 is not represented?

Sprints use 2 and 4 furlongs figs and routes use 4 and 6 furlong figs.
Either 2 or 6 is not used.

[JustRalph]

Sprints use 2 and 4 furlongs figs and routes use 4 and 6 furlong figs.
Either 2 or 6 is not used.

Thanks for answering that for me Tom.

Mike, thanks for putting up with me. Some great info in this thread. I appreciate everyones comments.

Let me explain..........a little.

There is a feature in Equisim that highlights all the numbers that equal the Bris par level, see attached pdf file. The yellow numbers meet or exceed the numbers that equal the bris par as listed at the top of the page. The par numbers are crap if you ask me and horses rarely meet the par and the numbers are pretty useless. For many years I made my own par levels and highlighted the race lines manually, especially when I really want to dig into a race. I had a job where my boss didn't care that I played the races as long as I was supervising the Techs on the floor. Highlighting and such is a tedious affair and literally gives me a huge headache. But, when I assign my own par levels I achieve much more success. I stopped doing it and went to Jcapper a couple years back. Now I ignore the par levels and exclusively use Jcapper, with a little help from the Equisim simulator when I want to use it. I exclusively use the Equisim PP's if I ever have to print them out. I just like them, I like the way I can manipulate the view etc. I have used the Bris PP generator and find Equisim much easier to use.

The one thing that changed over the last few years (besides a smaller ROI) was taking my own handicapping out of my game. I just don't see the races the same way I used to. I still hit a nice horse every once in a while, but not like I used to. A recent analysis of my play the last few years reveals that the really good long shots that I used to hit were the real reason I was profitable. Automating my system made it easier on me, but also made me less profitable. A huge chunk of my game back then involved printing pp's and spending time with them.

Using my highlighter and coming up with my personal par times might not be very efficient time wise, but I have come to realize that I relied very much on this and the comments in the PP's. Jcapper has some use of comments, but not what I want. Jcapper I will still use, but without moving to HDW data.... I am being left behind, and I just don't play enough anymore. I think the HDW data is great, but I have philosophical reasons also for not using it. I don't want to change over to SQL either. Which is where Jcapper has gone. Been there, done that........years back and hated it. Used SQL in my job and luckily I was able to offload it to subordinates.

My quest involves being able to manipulate the par times prior to loading the card into Equisim. This would save me a ton of time. Either by applying a set number (normally reducing the figures 3-8 points across the board on average, based on the perceived ml fav or my own perceived fav) therefore they print out or display already highlighted using the feature already built into Equisim. This would allow me to either use my own numbers, or import others I liked, for the set pars for the race. A way to just apply my reduction in figures to all par times in every race (per card) would be a sufficient jumping off point, and anything else beyond that would be gravy. I spoke with the original author of Equisim about this years back and he was able to convince me that doing it inside Equisim was probably not feasible, but doing it prior to loading the card might be.

Years ago, Nathan, the original author of Equisim included the feature at my request. The Bris numbers make it less than optimal, but helped. I would really like to improve upon it. At least it would be a great improvement for me. This improvement as best I can tell could come from manipulating the Bris file prior to opening it in Equisim. I am headed back to a more pen and paper handicapping model, with a Jcapper HTML report included.

We all have our own way of getting into the data. I am going back to my old style. At least partially. I want to play some more contests in the future also. I think my old style is a stronger hand in contests.......just another reason to head back in time.

I am open for suggestions. If I have to start sitting down with a highlighter again.........so be it.

On my other question from the original post... being able to strip a horse completely out of a race file would be nice, but I can do that with a black sharpie....after printing ....pretty easily.......... :lol:

[raybo]

You could open the csv file in Excel, that would put those par numbers in the same locations (cell locations) for every race on every card. Then you could get someone to write a macro that would make the desired changes to all the pars for all the races, with the click of a macro button. Then save as a csv file again and load it into your software.

[JustRalph]

You could open the csv file in Excel, that would put those par numbers in the same locations (cell locations) for every race on every card. Then you could get someone to write a macro that would make the desired changes to all the pars for all the races, with the click of a macro button. Then save as a csv file again and load it into your software.

Thanks for the info....... actually toyed with a similar solution years back....but the macro kept breaking on me........ will be up laying with it tonight......Thanks very much............

[JustRalph]

there has to be a better solution............ :bang:

[Mike at A+]

One of the problems I've had with the BRIS CSV files is "embedded commas" usually in the comments field. Things like "Speed, tired". This may be why your macro "broke". In A+, I had to write a "purify" routine that would temporarily change these embedded commas to semi-colons in order to correctly parse the file before processing. Back in the days of slower computers, the impact was significant on processing time but today this process runs very fast and no impact is felt.

[DJofSD]

I believe the issue of embedded commas in text fields has been eliminated.

For Super Saver in the BRIS single file format, the fields known as comments:

"04-10-10 Chased off rail; bid between; drifted; outfinished between",
"03-13-10 Away alertly; set solid pace; resisted to late; hung",
"11-28-09 Set pace; inside; repulsed bids; drew off; driving",
"10-10-09 Set pressured pace; weakened",
"09-11-09 Clear early; shook loose stretch; vigorous hand ride",
"08-22-09 Stalked 4wide; bid turn; 2nd best"


As expected, these text fields are delimited with the double quotation mark (' " '), what I like to refer to as BASIC strings -- strings as they would be created by any BASIC program when written to a file. Any commas seen above are field separators. Note the use of the semi-colon (' ; ') within the string fields.

[headhawg]

One of the problems I've had with the BRIS CSV files is "embedded commas" usually in the comments field. Things like "Speed, tired"When Handiman was originally coding Handifast this was the problem that he had. The commas appear in the fields that have to do with comments in foreign races (I forget the fields now). I had been working on my homegrown software and after about 50 man-hours of trying to debug that embedded commas problem I had written a workaround. I gave that code to Handi and that's how I wound up becoming part of the Handifast project.

But how stupid is that -- embedded commas in a comma-delimited file??? And I don't think that the problem has been solved. Just check some files from the Cali tracks as they seem to have the bulk of PPs for foreign horses.

[DJofSD]

Tripitaka, DMR, 2010-07-22, race 7:


"01-03-10 Made all; hung lft u.p. ov 1f out; styd on strongly",
"12-02-09 Made all; qknd 3f out; rdn clr fnl f; easily",
"10-08-09 Twrd rr; no response ov 2f out; sn wl btn; eased fnl f",
"04-22-09 Hld up bhd ldrs; prog 3f out to ld 2f out; led 1f out; readily"


These are the comments for the first four races of the horse, all at Kempton, England.

[cj]

Tripitaka, DMR, 2010-07-22, race 7:



These are the comments for the first four races of the horse, all at Kempton, England.

I know there Comprehensive Charts have some similar issues. They have commas inside quotes "strings" and they also have quotes inside of quotes...things like owner: "Jayeff "B" Stable" and Stakes race names like "Fred "Cappy" Capossela Stakes". There really is no excuse for it, but I get tired of complaining and just write workarounds.

[DJofSD]

The routine I wrote reads the entire string and does not assume anything about the fields other than a comma is used as a field separator.

If the start of a field is a double quotation mark then it ends with a double quotation mark. If the start of a field is not a double quotation mark then it is a character string and the field is terminated by a comma.

When a field starts with a double quotation mark then I find the end of the field by searching for ' ", ' or a double quotation mark concatenated to a comma. Searching for the ' ", ' eliminates the problem of finding a comma but not knowing if it is embedded or not.

When a field starts with anything other than a double quotation mark, I have found it is safe to assume there are not any embedded commas in the field and the next instance of a comma is the field separator.

[Mike at A+]

I believe the issue of embedded commas in text fields has been eliminated.

For Super Saver in the BRIS single file format, the fields known as comments:


As expected, these text fields are delimited with the double quotation mark (' " '), what I like to refer to as BASIC strings -- strings as they would be created by any BASIC program when written to a file. Any commas seen above are field separators. Note the use of the semi-colon (' ; ') within the string fields.
I suggested the semi-colon to them back in the mid-90's. Not sure when the actual change took place because I had a deal with another data supplier at the time and was getting my data files free of charge. But I remember tearing my hair out dealing with the earlier BRIS files trying to write a conversion routine. I remember some guy there being offended when I mentioned that I wrote a "purify" subroutine to change the embedded commas to semi-colons. Perhaps I should have chosen "friendlier" terminology.

[headhawg]

Tripitaka, DMR, 2010-07-22, race 7:



These are the comments for the first four races of the horse, all at Kempton, England.Yes, it looks like they cleaned most of it up by using semicolons now instead of commas. But if you have the DMR file for 7/28 you will notice that somewhere in it there is an extra comma. The routine that I wrote just lets me know that there's an error but not where it is. And there were plenty of errors in the files for the last SA meet.

It just seems ridiculous that the end users have to clean this up. I'm not a professional programmer and I did it. Why can't Bris?

[Tom]

They don't care?

(my guess):ThmbDown:

[Jeff P]

It just seems ridiculous that the end users have to clean this up. I'm not a professional programmer and I did it. Why can't Bris?
My belief is that the data comes that way from Equibase.

I say this based on having recently coded out file export routines enabling JCapper to create the equivalent of Brisnet .DRF and .MCP comma delimited text data files. The files created bear a .JCP file extension and are nearly identical to Brisnet .DRF and .MCP files in format, but the data inserted into the files comes from HDW.

While coding out the file export routines I discovered that many of the fields coming from HDW: chartcaller comments, owner names, breeders, etc. contained comma characters. This initially caused 3rd party apps like Handifast and Ray's All Data Spreadsheet to break when I tried loading .JCP files into them.

I wrote a separate clean up routine where the sole purpose was to physically look at all 1435 data fields one horse at a time and purge illegal characters. This took a lot longer to do that I ever imagined it would.

Given the amount of time it took me to write a set of working clean up routines for all 1435 data fields, I'm not at all surprised that you guys are finding commas in some of the Brisnet data files. Cleaning it up... every data field... in every file... From my own experience, that's a very labor intensive process.

-jp

.

[BillW]

One of the problems I've had with the BRIS CSV files is "embedded commas" usually in the comments field. Things like "Speed, tired". This may be why your macro "broke". In A+, I had to write a "purify" routine that would temporarily change these embedded commas to semi-colons in order to correctly parse the file before processing. Back in the days of slower computers, the impact was significant on processing time but today this process runs very fast and no impact is felt.

As far as I know commas have always been permitted in text fields (delimited by double quotes ("). Is this a Microsoft thing?

[Jeff P]

As far as I know commas have always been permitted in text fields (delimited by double quotes ("). Is this a Microsoft thing?
To the best of my knowledge, inserting comma (and other) characters into a string variable (example: "Tyler, Bautista, & Greene, Ltd.") doesn't break any rules of any programming per se. That said, comma characters cause problems because there are apps out there programmed to treat comma characters as always being the delimiter between data fields. Also, characters such as the ampersand have the ability to break routines using SQL expressions to read data from and write data to tables.

-jp

.

[TRM]

Ralph-

Check your PM.