|
JCapper Message Board General Discussion
|
| Home |
Register
Log In |
| By | Build Database Routine Problem | |
| jeff 9/9/2015 11:08:18 AM | I apologize for not posting about this sooner. RyeSteve sent me an email the night of Wed 09-02-2015 advising he was having trouble getting a build database routine to run: --quote: "On September 2, 2015 at 7:54 PM#######@*****.com wrote:--end quote --Here's my reply: --quote: "Steve, I just saw the same thing happen at my end when I rebuilt all files for race-date 08-30-2015 on a separate folder..."--end quote Yikes! I won't bore you with the rest of my email to Steve - but for the benefit of those of you who want to know the details I've posted the relevant background info below. But before I dive into that - here's a temporary 'fix' along with instructions for recovering from this... THE TEMPORARY SOLUTION - until I can publish a bug fix... Cut and paste the following .JCP and/or .XRD files onto a separate folder: Q3 2015... GPR0830.jcp GPR0830.xrd also, if you are building/rebuilding Q1 2015 ... OTC0127.jcp OTC0127.xrd Note that I said cut and paste NOT copy and paste. The offending files need to be physically removed from any data folder where you plan on running a db build routine. (Note: This applies to all build modes.) More specifically: Moving these files to another folder means they cannot be included as part of a build routine that you run on the folder the files were removed from. After removing the above files from a folder - you should be able build/rebuilt the remaining files on that folder without incident. How to tell if you are impacted by this: Q. How can you tell if your databases have been impacted as a result of this? A. Your databases are impacted if you face one of the following two scenarios: 1. If you were running daily Mode 5 builds like I was the individual entries in your StarterHistory table for race-date 08-30-2015 will be all starters for track codes APX-BTP-CBY-CLS-DMR-ELK-ELP-EMD-FER-FEX-GGX-GPR ONLY... And YOUR TABLE WILL NOT CONTAIN RACE-DATE 08-30-2015 ENTRIES for track codes from the followig list: GPX-LAX-MNR-MTH-PHA-PID-RET-RUI-SAR-SDY-TIM-WOX. Hint: The easiest way to check is to execute a query for that day in the Data Window while displaying individual starters. 2. If you ran a single Mode 4 build on the folder, the individual entries in your StarterHistory table will be all starters for only those track codes that sort alphabetically from A to G ending with R10 for track code GPR on racedate 08-30-2015... And your table will have no entries for track codes GPX through WYO that come afterwards. Hint: Again, the easiest way to check is to execute a query for the quarter in the Data Window while displaying individual starters. RECOVERY If either of the above two scenarios describe the state of your StarterHistory table follow the Best Steps for Recovery posted below. Best Steps for Recovery - SQL Mode: 1. Remove the GPR0830.jcp and/or the GPR0830.xrd file from your active data folder (per description posted beneath the Temporary Solution headline above.) 2. Launch the Data Window and execute a query to delete all starters from July 01, 2015 and later from your StarterHistory table. Hint: The following link will get you a text file that contains a sql expression that should do the trick: http://www.JCapper.com/MessageBoard/Reports/DeleteSQL_Q32015.txt Note: The Data Window will prompt you to confirm that you do in fact want to delete records. Double check the date text in your sql expression (you can cut and paste the expression directly from the linked to text file into the Data Window's SQL Expression Tool) and click OK at the prompt. Note: It may take a few minutes but after executing the query all Q3 2015 records will have been deleted from your StarterHistory table. 3. X-Out of the Data Window. 4. Relaunch the Data Window and run a Compact and Repair on your c:\JCapper\Exe\JCapper2.mdb file. After the Compact and Repair is complete - feel free to double check that all Q3 records were in fact deleted from the table by executing a date range query in the Data Window. After you confirm this, x-out of the Data Window. 5. Run a Mode 4 build on your Q3 2015 folder. That's it! At this point you should be good to go. Note: I posted the above steps under the assumption that you are using a quarterly folder structure. If you are using something other than a quarterly folder structure you'll need to adjust the date text in your delete query (step 2 above) and the folder that you rebuild (step 5 above) accordingly. Best Steps for Recovery - Playlist File Mode: 1. Remove the GPR0830.jcp and/or the GPR0830.xrd file from your active data folder (per description posted beneath the Temporary Solution headline above.) 2. Run a Mode 1 build on your Q3 2015 folder. That's it! At this point you should be good to go. Note: I posted the above steps under the assumption that you are using a quarterly folder structure. If you are using something other than a quarterly structure adjust the folder that you rebuild (step 2 above) accordingly. Relevant Background Info I run daily Mode 5 builds each morning (one day at a time) and it never occurred to me to sit and watch my builds run to completion. Maybe I should get in the habit of doing that. Debugging this a little... I noticed that the Mode 5 build routine for 08-30-2015 ran to completion through GPR R10 but stopped abruptly at that point... nothing for GPR R11... and no remaining card files processed for the 08-30-2015 raceday after GPR R10... More specifically: GPR R11 not processed and files GPX through WOX not processed. No error message. The db build abruptly terminated while processing the first horse in R11 of the GPR0830.JCP file. Digging deeper... I stepped through the code in the build database routine one line at a time and noticed the problem: None of the horses in R11 of the GPR file for 08-30-2015 have a morning line. This in itself should not be problematic as (for years) there has always been the occasional odd data file that has the occasional odd race (or races) that for many different reasons turn up without morning lines. And yes, race days where this has happened in the past are rare - but such dates do get processed during db builds. I believe this to be true because earlier this year the (Ocala Training Center) OTC0127.jcp file had a race with a missing morning line - and all card files for that date processed during my daily Mode 5 build. Digging deeper... Stepping through the code in the database builder one line at a time I can clearly see that the "missing" morning lines are a zero length string data type. That may or may not mean anything to you. (Whether or not it does depends on whether or not you have any programming experience.) My code in the database builder hasn't changed and contains tests with separate handlers for morning lines that are empty, missing, and/or null. So apparently the db builder was handling missing morning lines earlier this year and then last week suddenly started choking on them. It's not coming from a new program update. (I'm working on one but haven't been able to publish it yet.) It's not something new in the HDW files. I had a lengthy phone conversation with Ron Tiller at HDW on Friday and he proved to my satisfaction that zero length string data types for the occasional odd race where with a missing morning line is nothing new. (Missing morning line reported the same way in our HDW files since the beginning.) So what has changed? If there hasn't been a new program update and the way missing morning lines appear in the HDW files hasn't changed: My first best guess is that this HAS TO BE the result of some Windows Update. Or more specifically: A Windows Update that has changed the way the chipset on my machine tells 32 bit apps written in Visual Basic 6.0 to behave when a zero length string is evaluated. I can't prove it. Don't really WANT to. Proving it means digging through who knows how many Windows Updates - and from there start uninstalling them one at a time and running db builds until I stumble across the one causing the problem. I simply don't have that kind of free time. But a Windows Update is what I strongly suspect. Bug Fix I have a working Main Module at my end that contains a bug fix. The bug fix is two lines of code in the db build routine:
The first line tests the length of the MLine variable. Zero length strings are 0 characters in length. If the MLine variable is 0 characters in length program execution goes to the second line. There the MLine variable is coerced from a zero length string to a numeric 0. Neat. Clean. And after some unit testing I can see that it works just fine. The good news is that this will be part of the next program update. Now the bad news. Currently as I type this I have the guts of the Main Module torn open while I finish work on Build 198 (the upcoming program update.) I can't publish a bug fix yet - not even as a Main Module ONLY program update. Earlier this year I reached a point of no return... I had made so many changes to the program that the number of programming hrs it would take to revert back to a previous version has become larger (much larger) than the number of programming hrs it will take to finish the coming program update. So while I do have a working bug fix at my end - I can't publish it until I get the new program update finished and fully tested. |groan/grumble| The best I can offer you at this point is the Temporary Solution and Recovery Steps posted above. -jp . ~Originally posted by: jeff on: 9/7/2015 at: 10:25:08 PM~ ~Edited by: jeff on: 9/9/2015 at: 11:08:18 AM~
| |
| Caveat 9/9/2015 1:33:52 PM | thxs Jeff.. What should we do with the zip and unzip files for GPR 8-30?
| |
| jeff 9/9/2015 4:35:57 PM | Keep those removed GPR (and OTC) files in a separate folder - for now. When I do get the Main Module for Build 198 published - at that point - if you want starters from those GPR (and OTC) files to be included in your databases: Move them back to the appropriate folder - and from there do a rebuild. -jp .
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |