|
JCapper Message Board General Discussion
|
| Home |
Register
Log In |
| By | JCapperSDK.mdb file - unspecified error | |
| jeff 6/24/2019 12:04:40 PM | This morning while while the HDW File Mgr was running its XRD File Build Routine on an automated getCharts download : I started getting a series of error messages with text that reads "Unspecified error in Function writeChartData_JCapperSDK()." Fyi, I know some of you have reported this. I also know some of you have even figured out what to do on your own after encountering this. But this morning was the first time I (as in me personally) had the experience -- So I decided to write it up. I tried clicking through the error messages at first. But each time I did that, as soon as the routine began processing the next race, another error message appeared. I ended up bringing up Windows Task Manager, clicked the "Processes" tab, checked the box that says "Show processes from all users", right clicked the process named "HDWReader.exe *32", selected "End Process", and clicked the confirmation button that said "END PROCESS" to shut down the HDW File Mgr. From there I took a peek at the file size of the JCapperSDK.mdb file on my c:\JCapper\Exe folder: 533,664 kb (just over half a gig) A peek inside the file showed that my ChartRaces table had data for tracks that I've been playing dating back to 2009. (More about that later.) What I did to fix the problem: I got myself a much smaller current JCapperSDK.mdb file. I renamed my current c:\JCapper\Exe\JCapperSDK.mdb file from c:\JCapper\Exe\JCapperSDK.mdb to c:\JCapper\Exe\JCapperSDK_sav_06232019.mdb -- at which point I had an archived copy of the file. Renaming the file allows you to keep the ChartRaces data inside should you decide to access it later. FYI, while I'm not making my own speed and pace figs, although I could if I wanted to -- Having ten years of fractional times for every race at all of the tracks you've been playing sitting in a database can and does lead to some useful observations. So, rename the file first. (Don't just overwrite the old file with a new one.) After that, I copied the fresh blank version of the JCapperSDK.mdb file sitting on my c:\JCapperBuild folder to my c:\JCapper\Exe folder -- At which point I had a tiny brand new fresh blank JCapperSDK.mdb file sitting on my c:\JCapper\Exe\ folder -- At which point I tested things out by running and rerunning MANY automated get charts routines and subsequent XRD File Build Routines -- ALL of which ran to completion without error. My Working Theory about the Root Cause? I think my machine ran low on RAM memory at exactly the wrong time. Upon seeing the 0.5 gig file size of the c:\JCapper\Exe\JCapperSDK.mdb file -- And upon seeing that the ChartRaces table in my c:\JCapper\Exe\JCapperSDK.mdb file contained data that was a good ten years old -- It hit me that the root cause of the error messages could very likely turn out to to my machine running out of memory during the many read/write routines going on in the XRD File Build routine as each new race was processed. Fyi, I have the Rider/Trainer A/E History Type setting in my Enhanced Settings Module persisted as "-888 Jeff's FULL AE Profile", and I have the JCapperSDK setting in my Enhanced Setttings Module persisted as "-1 SDK Active during JCP & XRD File Builds". That means that the routine that performs the XRD File Build Routine in the HDW File Mgr is constantly reading and compiling rider and trainer data from the StarterHistory table in the JCapper2.mdb file and writing new/constantly updated rider and trainer data to the AEProfile table so that fresh rider and trainer ratings can be available for the next JCP File Build Routine. Also, the routine that writes to the ChartRaces table doesn't just append the current race to the table. Before it writes a race to the table it first checks whether or not that race exists in the table. In the event the current race is found in the table (most likely cause could be a revised chart/more on that a bit later) the routine edits existing data for the current race being processed. In the event the current race is not found in the table, then the routine writes the current race to the table. Even though you probably wouldn't think it would be that way at first glance -- The XRD File Build routine can actually be quite the memory hog. Right now as I type this, I'm guessing that the JET db driver might be tasked with keeping instances of BOTH the JCapper2.mdb file and the JCapperSDK.mdb file in RAM memory while the XRD File Build routine is being run. My working theory about the root cause of the error messages? On a machine that runs low on RAM memory during an XRD File Build routine Windows comes to a grinding halt, takes a snapshot of everything in RAM memory, writes everything in RAM memory to the swap file (also known as the paging file) and then restarts each actively running program window one process at a time, loading needed info for the current process being restarted from the swap file. If this freeze everything and write then read from the swap file takes too much time, the JET db driver can time out and lose its connection to an open .mdb file -- Thus the unspecified errors reported by the JET db driver to windows. That's my working theory. More to come... -jp .
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |