|
JCapper Message Board JCapper 101
|
| Home |
Register
Log In |
| By | JCapper2 file size | |
| parshooter 12/27/2019 12:24:05 PM | You have mentioned previously not to have too large a JCapper2.mdb file size. It is near end of year is this a good time to downsize? Currently my file size is 1,291,668 KB. Is this too large and could it cause problems?
| |
| jeff 12/30/2019 10:05:32 AM | At 1.2 gigabytes -- If you're building daily in Mode 5 then you're ok in terms of file size. If you plan to build or rebuild quarterly, you may not be ok in terms of file size. I say that because I recently had a quarterly db build fail to run to completion because it errored out when the J2 file broke the 2.0 gigabyte file size barrier. Fyi, that particular J2 file contained data spanning Jan 01 2018 through Jun 30 2019 and was about 1.41 gigabytes in size when I began a quarterly build for Q3 2019. I'm basically borderline fanatical when it comes to making backups of my .mdb files:
Historically, I've been able to squeeze about 24 months of data into a J2 file. So naturally I was curious how and why that particular J2 file managed to break the 2.0 gigabyte file size barrier. After installing a known good backup J2 file current through Jun 30 2019, I began running a Mode 4 build (with the Chron Build setting enabled which causes db builds to run in chronological order) on my Q3 2019 folder - and from there I monitored the build. I was kind of stunned (about halfway through the month of Jul 2019) to see that the file size of the J2 (which was 1.41 gigabytes at the start of the build) had ballooned to about 1.8 gigabytes about 2.5 weeks into the build. Keep in mind that July is the peak season - the month each year with the highest number of thoroughbred races. The J2 file eventually breached the 2.0 gigabyte file size barrier and errored out in the middle of a Sep 27 race card - about 3 days shy of running to completion. Knowing that I have ALWAYS been able to get at least 24 months of data into a J2 file using Mode 5 daily builds, I unit tested the following scenario: On the same machine, I created three separate monthly folders: Jul 2019, Aug 2019, and Sep 2019 -- I then copied .JCP files, F*.txt chart files, and .XRD files for each month onto the appropriate folder. I then reinstalled a known good backup J2 file current through Jun 30 2019. From there I was able to run Mode 4 builds on each of the separate monthly folders (Jul 2019, Aug 2019, and Sep 2019.) Each of monthly builds ran to completion without error. While monitoring J2 file size during each of those three monthly Mode 4 builds -- and while monitoring J2 file size during daily Mode 5 builds for July 2019 on another machine: At no time did J2 file size during those scenarios ever come close to breaking the 2.0 gigabyte file size barrier. But the same J2 file about 2.5 weeks into a quarterly build during the month of July was constantly in danger of breaking the 2.0 gigabyte file size barrier (and eventually did.) Conclusion: If you value your work, make regular backups of your .mdb files:
You never know. Sorry for the long rant. But your question deserves a thorough answer. -jp .
| |
| jeff 12/30/2019 12:54:27 PM | Year end is generally a good time to archive/downsize a J2 file. But you needn't wait for year end. I use Prob Expressions to score rider, trainer, post position, and recent early-late bias for the track-intsurface-dist. Because of that - I prefer to have at least one year of data in the J2 Staterhistory table for tracks I am currently playing. But I also want the smallest possible J2 Staterhistory table for tracks I am currently playing - because operating that way means faster Calc Races routines during live play. To satisfy both objectives: Once a week or so (especially during summer months when lots of tracks are running) I'll use the J2 Imports Module to export Staterhistory table data out of older larger archived source J2 file(s) into a fresh new smaller J2 file for purposes of live play. The ability to use user defined sql expressions to drive J2 exports helps. My point? -- Don't think you have to wait for year end to set up a J2 .mdb file for live play. And don't be afraid to roll your own. As long as I'm posting about maintenance of .mdb files in JCapper -- The Main Module is programmed to automatically run a compact and repair on the J2 .mdb file at the end of each db build routine. But (to date) I haven't programmed the Main Module to run a compact and repair on the J1 or SDK .mdb files. It's a good idea (every 3-4 days) to bring up the Data Window Menu and run a compact and repair on your J1 and SDK .mdb files. Year end is also a good time to archive your JCapperSDK.mdb file - and start each year off with a fresh blank JCapperSDK.mdb file. -jp . ~Edited by: jeff on: 12/30/2019 at: 12:54:27 PM~
| |
| parshooter 1/2/2020 10:02:51 AM | Thank you for your reply. I am not certain how to archive current SDK file. Also, couldn't find instructions on message board to create a new SDK file. Please advise.
| |
| jeff 1/2/2020 10:39:56 AM | Same way you'd archive a JCapper2.mdb file: 1. Rename the file. Changing the filename from JCapperSDK.mdb to something like JCapperSDK_YE2019.mdb will get the job done. 2. Copy the renamed file to some other media such as backup on the cloud, external hard drive, a thumb drive, and/or a second thumb drive, etc. 3. Take the fresh blank current version of the file (in this case the JCapperSDK.mdb file) from your c:\JCapperBuild folder - and copy it to your c:\JCapper\Exe folder. That's It! -jp .
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |