|
JCapper Message Board
JCapper 101
--
Fatal Error - JCapper2.mdb file not found on app.path folder
|
|
By |
Fatal Error - JCapper2.mdb file not found on app.path folder |
jeff 3/28/2013 9:36:22 AM | --Quote: | "
Help! Windows froze up while I was in the middle of a sql (mode 4) build database routine. I had to restart my machine.
Ever since the reboot I get an error message advising that the JCapper2.mdb file is missing whenever I try to launch the JCapper Main Module. The text of the message reads as follows: Fatal Error - JCapper2.mdb file not found on app.path folder.
When I navigate to my c:\JCapper\Exe folder I can clearly see that the JCapper2.mdb file is in fact there.
FYI, I do have a good backup JCapper2.mdb that I made just prior to my last program install.
Q. What should I do? What is the best recovery path?
"
--End Quote. |
Background Info If Windows froze in the middle of a sql database build, its likely that the Jet database driver lost its connection to the database. If this is the case its likely that data fields in the JCapper2 tables for the starter being handled by the db driver at the exact point in time when the connection was lost contain incomplete or invalid values.
When you first start the Main Module it performs a series of tests that determine the presence of and the state of the tables in the JCapper2.mdb file. The error message you are describing describes a JCapper2.mdb file that has become corrupted. (Breaking out of a Build Database routine has the ability to do that.)
One way to repair things is to run a Compact and Repair Database routine from the Data Window MENU. However, if the JCapper Main Module wont start for you – you need to go elsewhere to run a Compact and Repair.
If you happen to have it installed on your machine you might try running a Compact and Repair on the c:\JCapper\Exe\JCapper2.mdb file from inside of Access 2003.
That said, a compact and repair – provided you can run one in the first place - will not fix the problem completely. At best, it will only render the JCapper2.mdb file usable again.
Important Note: After running a compact and repair, your StarterHistory table is going to be populated with valid data for the last starter processed before your machine froze up. Any and all horses after that will not have been processed yet. So my recommendation would be to skip running a Compact and Repair for now – and instead install the fresh blank current version copy of the JCapper2.mdb file sitting on your c:\JCapperBuild folder.
The recovery instructions presented below will lead you through that process.
RECOVERY INSTRUCTIONS:
1. Navigate to your c:\JCapper\Exe folder and rename the JCapper2.mdb there to something else to get the file out of the way. Hint: Renaming the file to JCapper2_BadFile.mdb gets the job accomplished.
2. Navigate to your c:\JCapperBuild folder. On that folder is a fresh blank current version JCapper2.mdb file put there during your most recent JCapper program install. Copy this file (filename: JCapper2.mdb) to your c:\JCapper\Exe folder.
3. Launch the JCapper2 Import Screen.
Hint: The launch button on the Utilities Screen of the WagerHistory Module will serve to get the job done.
Note: Steps 4-10 below are all performed while you are in the JCapper2 Import Scree.
4. Click the Set Source Database button. Use the dialog box to select a source JCapper2.mdb file.
Hint: Selecting the last known good backup JCapper2.mdb file gets the job done.
5. Click the Set Target Database button. Use the dialog box to select a target JCapper2.mdb file.
Hint: Select the JCapper2.mdb file on the c:\JCapper\Exe folder from step 2 above to get the job done.
6. Look at the checkboxes on the JCapper2 Imports Screen. Check the box for each table that you are knowingly using.
If you are not sure whether or not you are actively using a given table – chances are you aren't using it and can leave the box unchecked.
The following list will probably get the job done for 98% of you:
• StarterHistory Table.
• SQL Mode F Factor Setup. Hint: Check this box only if are using a custom factor setup.
• SQL Mode Customizable HTML Report Layout. Hint: Check this box only if are using a custom factor setup.
• UDM Wizard Recovery Screen History.
• TripNotes Table. This table has VetScratches info parsed from the XML in it. Most of you should check the box.
• WagerHistory Table. Hint: Check the box. Only you know if you are using this table. If you are not using it why are you not using it.
• ToteCodes Table.
7. Double check the folder and file names of your Source Database File and Target Database File.
8. Double check the boxes checked for the tables you want to import out of your source database file into your target database file.
9. Click the GO button – and click ok through the X number of records imported messages as the interface performs the import for each table.
10. After the Import Routines have been completed for all of the tables you checked, x-out of the JCapper2 Import Screen (and WagerHistory Module.)
At this point, you now have a working current version JCapper2.mdb file sitting on your c:\JCapper\Exe folder populated with data as it existed at the time of your last known good backup.
At this point you should be able to launch the JCapper Main Module as well as the other JCapper modules without getting an error.
At this point, you should be able to load data files into the program - get scratches by parsing the XML - run a sql Calc Races - and generate race day reports that reflect your UDMs and custom sql report layout.
However, we are not yet done...
-jp
.
~Edited by: jeff on: 3/28/2013 at: 9:36:22 AM~
| jeff 3/29/2013 10:02:00 AM | Continued...
The next set of instructions will lead you through the process of bringing the StarterHistory table current – or populating it with data for starters from data and results files that were downloaded or added to your machine after the point in time when your last known good backup JCapper2.mdb file (from step 2 above) was created.
RECOVERY INSTRUCTIONS - BRINGING THE STARTERHISTORY TABLE CURRENT:
1. Determine the calendar cutoff point for the data sitting in your StarterHistory table.
Launch the Data Window in SQL Mode, set the Data Window to display individual starters, and execute a query like the following:
SELECT * FROM STARTERHISTORY WHERE RANKUPR = 1 ORDER BY [DATE], TRACK, RACE
Note: I am purposely using a rank = 1 for a single factor query because I want to limit the query results to one horse per race. Limiting the results to 1 horse per race has the advantage of taking less time to execute than if my query returned all starters in the table.
Note: The order by clause in the second line of the query causes the returned query results to be sorted by date first, track code second, and race number third. This makes it easier to determine the calendar date of the last race in the table than if the query results had been sorted a different way (or not sorted at all.)
Once the query has finished executing, scroll all the way down to the very bottom of the results set and look at the date displayed for the last starter in the table. Note this date as it is the race date as read from the chart file for the very last starter that made it into your StarterHistory table.
2. Does the calendar cutoff date determined in step 1 above indicate that your StarterHistory table contains PARTIAL data for a calendar folder?
For example, you are using a monthly or quarterly folder structure and the date that your data cuts off is somewhere in the middle of the calendar time period for that folder.
3. If the answer to this question is NO – great. Your job just got easier. In that case - look at your folder structure and determine what data is missing from your StarterHistory table.
If the race date of the very last starter in your StarterHistory table happens to the last race date for the calendar time period covered by one of your data folders – bringing your StarterHistory table current becomes a simple matter of using the Database Builder to build the data folder for the time period that immediately follows your cutoff date.
Hint: Use Mode 4 to build the appropriate folder.
From here, provided the answer to this question is NO, just keep repeating step 3 above until you have brought your StarterHistory table current. (And then make a backup of your JCapper2.mdb file at which point we are done!)
4. However... If the answer to the above question is YES – if the cutoff date from step 1 above indicates that your StarterHistory table data cuts off in the middle of a calendar time period covered by one of your data folders – you are going to have to delete all data from that time period from your StarterHistory table.
Before moving on, I will define what I mean by time period.
If you are using a quarterly folder structure, you will delete all data from that calendar quarter. Which quarter? The quarter where your cutoff date from step 1 above happens to fall on the calendar.
If you are using a monthly folder structure, you will delete all data from that calendar month. Which month? The month where your cutoff date from step 1 above happens to fall on the calendar.
Got it?
Q. How do you delete data from the StarterHistory table?
A. Launch the Data Window in SQL Mode. Click the SQL button and key a sql expression that contains a delete statement in it into the SQL Expression Tool.
Sample SQL Expression for deleting a calendar time period:
D E L E T E * FROM STARTERHISTORY WHERE [DATE] >= #01-01-2013# AND [DATE] <= #03-31-2013#
Important Note: In the above expression I had to add spaces to the word delete so that I could get the message board's security layer to accept it. That means YOU will need to remove the extra spaces in the event you decide to cut and paste what I have posted into the SQL Expression Tool in your Data Window.
Important Note: In the above sql expression I have wrapped the word date with square brackets. (Always do this.) Also note that I have wrapped the text of the start and end date with pound characters. (Again, always do this.)
Also note that the text dates I am using in this example are for Q1 2013. Adjust your own text dates accordingly. Yours would be the start and end dates of the time period covered by your calendar data folder.
After double checking the query sitting in your SQL Expression Tool – click the Execute button to execute it. Answer YES when prompted to tell the Data Window that you do in fact know what you are doing and that you do in fact wish to delete records from the table.
5. After deleting records from the table, run a Compact and Repair Database Routine on your c:\JCapper\Exe\JCapper2.mdb file. In the Data Window, click MENU, click COMPACT AND REPAIR JCAPPER2.MDB FILE – answer YES when prompted and run the routine.
From here, repeat steps 1, 2 , and 3 as needed until your StarterHistory table has been brought current.
That's it!
Whew!
-jp
~Edited by: jeff on: 3/27/2013 at: 8:55:51 PM~
~Edited by: jeff on: 3/29/2013 at: 10:02:00 AM~
| Buckabeer 3/27/2013 11:11:41 PM | Wow I'm tired out and my head is spinning from just reading this !!!
| jeff 3/28/2013 8:49:01 PM | Hey, hopefully no one else ever finds themselves in a position where they have to USE the info posted in this thread.
However, one guy did.
I figured rather than write it up as a private email, why not post it here publicly?... Where if it is needed again at some future date - at least the info is visible to a search.
-jp
.
|
|