|
JCapper Message Board JCapper 101
|
| Home |
Register
Log In |
| By | Corrupt Bris Files | |||
| Jens 7/12/2012 7:22:50 PM | Anyone know who to contact about corrupt Bris .drf or .xrd files? Both Indiana and Presque Isle for 7-11 cause my database to fail when I try to build or append. All other tracks were ok that I downloaded.
| |||
| bettheoverlay 7/12/2012 7:51:23 PM | I had the same problem with those two tracks. Today, the Belmont xrd file is corrupt, although Woodbine, Calder, Louisana, Arlington were fine. techsupport@brisnet.com
| |||
| Jens 7/12/2012 8:27:32 PM | Thanks for the heads up on bel today. I set up a new folder for todays tracks and belmont was indeed corrupt. Hope this doesn't become a habit. Anyhow, email sent and thanks again.
| |||
| jeff 7/13/2012 12:48:02 PM | Not my doing guys... Looks like Brisnet is in the middle of reformatting the data fields in their files. At this point in time I don't know what their intentions are, where they are going with this - how many data fields are impacted, which data fields will be impacted going forward, etc. Feel free to email me matched pairs (both the data and results file) for any problem race cards. jeff @ jcapper . com (remove the blank spaces first) I'll add files received to test folders at my end - run db builds - and see what I can glean. (But I need a collection of files first.) -jp .
| |||
| bettheoverlay 7/13/2012 2:39:09 PM | Jeff, I have emailed the three files that are bad. I downloaded them again a few minutes ago and had the same negative result.
| |||
| mikejlb 7/15/2012 2:44:15 PM | BEL0715 drf won't load with this error "incorrect number of data fields"
| |||
| bettheoverlay 7/16/2012 9:52:29 AM | That's strange as I had no problem with yesterdays BEL drf or xrd. In fact I haven't had anymore problems with any tracks except for the three already mentioned.
| |||
| Jens 7/16/2012 1:51:32 PM | That really is strange. All my files yesterday were good but I did get corrupt files for FLX on 7-13 and DEL on 7-14. I just re-downloaded those files and still get the error message. Wondering- Did Bettheoverlay download those tracks and get them to work? And does Jeff want me to send those two track DRF and XRD files to him?
| |||
| bettheoverlay 7/16/2012 3:56:43 PM | I did not download those tracks (FLX and DEL) on those dates.
| |||
| jeff 7/17/2012 12:46:23 PM | Until further notice, if you get a bad file, please send it to me. This doesn't appear to be an intentional Brisnet formatting change. However, someone at Brisnet has done something (unintentional) that is causing them to sporadically publish the occasional bad file. The more examples I can show them, the easier it gets for them to take it seriously, get it corrected, and prevent it from happening going forward. -jp .
| |||
| Jens 7/17/2012 8:26:46 PM | Jeff, I've e-mailed you the files for FLX 7-13, DEL 7-14, and MNR 7-16. Good Luck!
| |||
| jeff 7/18/2012 4:58:19 PM | An update... I received a call back from Happy Broadbent today. From there, he put me in touch with Corby Corbett. Based on the phone conversation that Corby and I had I think I will be able to create a work around for those of you downloading .XRDs from Brisnet. It might take a day or two... but I will include it as part of the next new program update. Thanks for your understanding and patience. -jp . ~Edited by: jeff on: 7/18/2012 at: 4:58:19 PM~
| |||
| bettheoverlay 7/19/2012 7:01:25 AM | The xrd files I downloaded yesterday (7-18) for DMR-PID-WOX, all three, created DAT files that were race headings only, as if they were quarterhorse or arabian races.
| |||
| Jens 7/19/2012 5:39:38 PM | At this point it almost seems a waste of time to download xrd files as all of them I downloaded yesterday did what bettheoverlay said.
| |||
| jeff 7/19/2012 8:31:01 PM | Hey Guys, Thanks much for the files. Please keep sending them. I haven't downloaded from Brisnet since converting to HDW. The more files you send, the more complete my testing environment becomes - and the faster all of this becomes a thing of the past for you. I spent the day rewriting and testing a new VB parse routine. For those of you who are familiar with VB6 (or VBA inside of Access or Excel) I found that using a Line Input # statement (to read the data file one LINE at a time) followed by a Split command (to split the line just read into individual array items) enables the recently revised files to be parsed at will. That's the good news. Now the bad news. In my original parse routine I was parsing the record for each horse ONE DATA FIELD AT A TIME and inserting the value for each data field read into array variables for calculations/number crunching, etc. There's something in the data that breaks that legacy routine - which has been in use unedited since about 1995. Long story short: The new parse routine appears to work. The downside is that it's going to take me several days to get it written into all of the different places in JCapper where comma delimited files are being parsed. (From there it has to be thoroughly tested before I can publish.) One (new) minor annoyance that I noticed.... Horse names in .MCP and .DRF files are upper case - while the names for the same horses are a mixture of upper and lower case in the new .XRD files. Various methods of name matching fail under those circumstances. Easy enough to correct with a UCase or LCase statement. However, there are a lot of places in a lot of programs and spreadsheets out there where the program author didn't have to contend with UCase or LCase in the past because the data was cased the same in both files. This impacts you because I need to get an exact name match so that the past performance record and the results record for each horse can be matched up and written to a database. Those of you reporting that the 7-18-2012 .XRD files resulted in .DAT files that contain 0 records - see the above paragraph as it describes the exact cause. If someone were to ask me for a preference - Enforcing an info model where all text fields in common (track code, horse, rider, trainer, owner, sire, etc.) in both the data file and the results file are an exact match (character for character including case) would be the way to go. That's what I asked Brisnet for earlier today. If and when they adopt that info model they will make someone's life easier down the line. But it won't likely be me - Looks like I'll be writing lots of LCase and UCase evaluations into the new parse routine. A note for the programmers among you: There's definitely something quirky in the recent Brisnet data that breaks my legacy parse routine. Using VB6, if you read the data file one field at a time using an Input # statement - and then update an array with the value of the data field just read - when you parse out data for the horse CHRISTOFER'S JOY (R8, BEL0712) one or more of the fields somewhere in the middle of the file parse out as if there are 2 fields there - causing the items in the array after that point to be different from anticipated data types and values. I'll eventually isolate the individual data fields(s). Oddly enough, a Line Input # statement to read the same data file one line at a time used with a Split command to insert the line of data just read into the very same array works just fine. Strange. A note for those of you who are thinking about waiting before downloading .xrd files: Keep in mind that they only keep files up on their server for a few days. After the links to those .xrds get rotated out, the only way to get a missing file is to go through their Archive Server. Now you know what I know, -jp .
| |||
| Tom C 7/21/2012 4:37:27 AM | Jeff, I have just done a database build from scratch with .mcp and .xrd files for 7/18, 7/19, and 7/20 and got a populated pl_profile file of over 5 megabytes. I had downloaded the 7/18 and 7/19 .xrd files again to see if the corrections had been made. Hopefully my pl_profile file is good. Tom C
| |||
| bettheoverlay 7/21/2012 10:01:07 AM | All the Bris xrd files I downloaded yesterday (7-20) APX-DMR-ELP-PID-SAR-WOX worked. The previous 2 days none worked. Very strange.
| |||
| jeff 7/21/2012 10:37:22 AM | Corby at Brisnet emailed the following note to me yesterday:
The format change back to upper case names for both data and results files (instead of upper case in data files and a mixture of upper and lower case in results files) enables the legacy WorkFile Importer in JCapper to get a name match - and it fixes the 0 record .DAT files issue caused by .XRD files produced for July 18th and 19th. Recommendation: Redownload all results files 7/18/2012 and later that you can - and use them to replace existing results files. -jp . ~Edited by: jeff on: 7/21/2012 at: 10:37:22 AM~
| |||
| jeff 7/21/2012 3:31:23 PM | An update... Example that illustrates one (recurring) problem that I found: Screenshot: BEL07122012MCP_field378.JPG 1. The above linked to screenshot shows specific data fields for the horse CHRISTOPHER'S JOY in the BEL0712.MCP file. The screenshot shows the data displayed in two open instances of Notepad. Each open instance of Notepad shows data field content and the position in JCapper's internal array variable after being parsed from the data file. The specific offending quirk that breaks my legacy parse routine is the set of double quote characters embedded in the string text for data field #378. 2. The open instance of Notepad on the right shows the data parsed out using the newer parse routine based on a Line Input# statement followed by a Split command. (VB6.0 or VBA inside of Excel or Acccess.) Using this methodology to get at the data parses field# 378 out as a single field where: a. The double quote characters become visible to the naked eye. b. All subsequent items in the array after the double quote characters are encountered fall into the correct array index positions - where the index in the array for each data item matches exactly the field number for that data item as listed in the Library area of the Brisnet site. 3. The open instance of Notepad on the left shows the data parsed out using my legacy parse routine based on a (VB6 or VBA inside of Access or Excel) Input# command where data in the file is read from the file one data field at a time and added to an array variable immediately after being read from the file. Using this methodology, when the embedded double quote characters are encountered, the following chain reaction occurs inside of Visual Basic: a. The string inside of field# 378 is parsed out as 3 separate data items ("Fred ", "Cappy", and " Capossela S.") instead of the intended single data item. b. The result of making VB think it has parsed 3 data fields instead of a single field is that the index positions for all items in the array for all data items parsed from the file after the double quote characters are encountered "jump" two positions. Because of this, all of the data parsed from the the file after the double quote characters are encountered is rendered useless. I hope I managed to explain most of that in a way that makes sense. I've asked Brisnet to remove all instances of double quote characters (as well as all non keyboard characters) from all strings inserted into .MCP, .DRF, and .XRD files. Doing that would be a big help to not just myself but to anyone using Visual Basic (or VBA inside of Access or Excel) to parse out Brisnet comma delimited data files. -jp . ~Edited by: jeff on: 7/21/2012 at: 3:31:23 PM~
| |||
| bettheoverlay 7/21/2012 7:09:50 PM | I re-downloaded the 18th and the 19th earlier today and the xrd files are still bad. I was successful with today's (21st) early track xrds
| |||
| jeff 7/21/2012 8:08:44 PM | An update... Dare I say it? For the first time in a week I'm actually encouraged by what I'm seeing. I now have a prototype Main Module that includes a revised Brisnet file parse routine. The revisions in the parse routine handle all of the file formatting changes that I've been able to find in the files sent to me by you guys. Just a few minutes ago I was able to successfully run Build Database routines in Mode1 (and only Mode 1) on two different folders: 1. A folder that contains all of the .mcp and .xrd matched pair files sent to me. 2. A second folder that contains all of the .drf and .xrd matched pair files sent to me. From here, I need to write the new parse routine into the places in the Main Module that control the other build modes - and then test for Build Modes 2, 3, 4, and 5. If all goes well I should be able to publish as part of a new program update as early as Mon or Tues. -jp . ~Edited by: jeff on: 7/21/2012 at: 8:08:44 PM~
| |||
| jeff 7/22/2012 4:07:01 PM | An update... I was hoping to publish a program update tonight that would have enabled you guys to (at least) run Mode 1 database builds on your Brisnet .DRF and .MCP file databases. But that's on hold - at least for the time being. Someone sent me a copy of the BEL0715.DRF file. This file is scrambled in such a way that there's little or no point in me writing a work around into my new file parse routine until I hear back from Brisnet. This morning I spent a few hours debugging - isolated the problem down to a single horse - and from there down to the offending data fields (#376- #385 for Racename of previous races.) Next I created a detailed explanation of my findings - and then sent it off to Corby and Happy at Brisnet. Sadly, it only takes one bad data field to render an entire file useless. I am at the point now where I have taken this as far as I can. From here it's up to Brisnet to fix a few things at their end so they can start producing files once again that are formatted in a manner that is consistent from one file to the next. I will post a further update once I hear back from them. -jp . ~Edited by: jeff on: 7/22/2012 at: 4:07:01 PM~
| |||
| Jens 7/22/2012 11:41:30 PM | Let me start by saying that your customer service/support is so amazing that it leaves me in awe. In an industry where customer service borders on nonexistent yours outshines the best of customer service friendly industries. Two huge thumbs up from me! I have to confess that at the present time I am somewhat confused as to the need for an program update. Since you contacted Bris and they made changes all new files seem to be fine. Most mysterious to me is that I never had a problem with Bel 7-15 drf. xrd. or building that dat file. I'm not a computer guy so maybe something is going on behind the scenes that I don't get but only losing the first five tracks (Ind 7-11, Pid 7-11, Bel 7-12, Flx 7-13, and Del 7-14) in a database of thousands of tracks isn't that big of a deal to me. At present everything "seems" to be fine. Am I missing something? Let me finish by once again giving you a big two thumbs up and thank you for your great program and awesome customer support. Jens
| |||
| bettheoverlay 7/23/2012 9:23:39 AM | The 18th and 19th xrd files are now good so I'm only missing three files which I too can live without. Everything from the 20th on has been good. Thanks so much for your help in this, Jeff, especially considering there doesn't appear to be many Bris customers left on Jcapper.
| |||
| JimG 7/23/2012 9:39:20 AM | I am still a bris customer and appreciate that Jeff has not abandoned those of us that download with them. Jim
| |||
| jeff 7/23/2012 12:20:34 PM | An update... Brisnet has had the chance to digest what I sent them over the weekend. Better yet, they agree with everything I said and are working to get their routines modified. When they are done, and my thinking is they will be done within 2-3 days (maybe sooner) - the files they will be producing at that point should be 100% JCapper compatible again. THANKS for your continued patience and understanding in this matter. -jp .
| |||
| jeff 7/24/2012 3:34:02 PM |
If Brisnet gets their act together and cleans up the data being inserted into their files again - AND if they make replacement files available for the bad ones published over the past 7-10 days - then obviously there is no need for me to do a program update. The first several conversations I had with them went something like this:
Based on those initial conversations, it didn't appear they had ANY interest in cleaning up the garbage they had introduced into their files. Under those circumstances, if I were going to continue supporting their files in JCapper, a program update was an absolute must. The first order of business was to figure out - as in specific characters inserted into specific data fields for specific horses - what changes they had introduced into the data that was causing Visual Basic to "break." I ended up writing my own File Editor/Debugger... a VB program that would read the data for each horse in the file one data field at a time... create an attribute list about each data field read from the file... and then write desired attributes about each data field to a text file that could be popped open in Notepad - making the whole thing visible to the human eye. Being able to SEE the data itself presented neatly in columns and/or rows - as well as the ability to analyze data about the data... VarType, Length of each string, the ASCII code for each character in the string, etc. - is what enabled me to debug this. I'd still be chasing it if I hadn't written my own debugger. It wasn't until I started pointing out problems about specific data fields for specific horses that I was able to finally convince them they had a problem that needed to be addressed. As to why some of you are reporting good files for a race card and others are reporting a bad file for the same card... Here are a few of the different customer experiences - that I think pretty much illustrate what has been happening over the past week: Someone downloads a bad file - calls them up, reports the file to them as bad - catches the right person on the phone at the right time - They see why it's bad... and decide to make a corrected (new) file available for download. Someone else downloads the original bad file, gets an error message - scraps the bad file - and works with the 7 other good files they downloaded that day. Someone else comes along later, downloads the corrected file only - gets no error message - and wonders what all the the fuss is about. Someone else downloads 7 files that day - and through simple act of fate manages to avoid downloading the 2 bad ones - and wonders what all the fuss is about. -jp . ~Edited by: jeff on: 7/24/2012 at: 3:34:02 PM~
| |||
| jeff 7/28/2012 12:22:15 PM | An update... I spoke with Corby at Brisnet yesterday. He indicated that files produced by them starting 7/15/2012 and later should be "clean" in terms of the extra characters issues that I pointed out to them. During this past week, no one from the JCapper user community sent me any more examples of bad files. If anyone did download a bad file this past week, please let me know ASAP. I'm hoping that the number of bad files being downloaded is back to zero again (and to be able to close the book on this episode.) Please let me know... -jp .
| |||
| Caveat 7/29/2012 10:31:21 AM | Jeff... This is something similar .. I keep getting a report saying that SAR 7/15 results are missing in my HDW database..it looks like there were 3 hurdle races ran on that day with no payouts...... How can I get rid of that exception ?
| |||
| jeff 7/30/2012 12:06:36 PM | the SAR 07-15-2012 file was steeplechase only - and a NON BETTING card. No chart file is forthcoming. My recommendation? Simply do nothing. The SAR0715 card will appear on the Exception Report as if it were a cancelled race card. Or, alternately, to remove it from the exception report for your next build database routine: Delete the SAR0715.JCP file. In general, the Exception Report tells you two things: 1. Cancelled race cards. (When a card is cancelled you are likely to have downloaded a data file - but no chart file is ever produced.) 2. Files that you still need to download. When a data file appears on the Exception Report it means you downloaded the results file but not the data file. When a results file appears on the Exception Report, it usually means one the following three cases: a. The race card itself was cancelled. b. Something in the chart data itself (incorrect times, missing fractions, etc.) caused HDW's validation tests to flag that chart as suspect. Note that Equibase has similar routines but they are (my opinion) too "loose" and allow far too many bad data items to find their way into the data. Imho, HDW spent the man hours and made the effort to identify where the outliers in the data were coming from adjusted their validation routines accordingly. Among the various data providers they are the ones most likely to catch bad data before it makes it into a file. (Brisnet, DRF, Equibase, Trackmaster not so much.) When a bad data item in the chart data is identified, HDW will put that chart file aside and ask Equibase to give the bad data item a second look. Often times the race can be re-timed (by hand) and the bad data item corrected. (Other times not.) Afterwards, Equibase will republish the chart (with the info corrected if possible.) At that point, HDW will publish their chart for that card and make it available for download. Note that if a race card did not cancel, and when HDW is slow to publish charts for that card - and other data providers have published charts for that card - there's a 98% chance this means something in the chart data is bad. c. Then, there's the simplest case of all. The missing results file on the exception report is pointing out a file that you still need to download. I hope I explained most of that in a way that makes sense. -jp .
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |