|
JCapper Message Board JCapper 101
|
| Home |
Register
Log In |
| By | Moving UDM's to SQL | |
| pdavid6 9/22/2009 4:01:05 PM | Jeff, How do I move my existing UDM's that are in playlist mode to show up on the SQL html report? Thanks, Phil
| |
| jeff 9/22/2009 9:43:42 PM | Phil, I'm still working on a video that explains SQL UDMs. Bear with me... It's powerful stuff.  -jp .
| |
| jeff 9/23/2009 9:18:05 PM | 18 minutes on SQL UDMs... SQL UDMs Video http://www.JCapper.com/PodCasts/SQLUDMs.wmv Key things to take away from the video: 1. UDMs can be SQL... OR they can be PlayList File based... they can't be both... so don't try yo mix and match. Decide beforehand whether you want a UDM to behave as a SQL UDM... or as a PlayList File UDM... and create accordingly. 2. Odds based factors constraint in SQL UDMs merit special handling. When you click the Calc Races button on race day the Profile Marker doesn't know what the odds are. So avoid saving SQL Expressions that include parameters for odds based factors... Odds, RankOdds, BettorsToteProb, EBettorsToteProb, OR3, etc... Use them in your R&D... but avoid them when it comes time to save the SQL Expression that represents your UDM Definition. When in doubt - check your work. Verify that any new UDM "fires" by running a Calc Races on a card or race where you fully expect it to fire. Verify that it does in fact flag the horses you want it to flag before moving on to a different UDM. Create "triggers" for yourself during play or pass decision making - consider keying a note to yourself in the BettingInstructions field... Example: You want E~BettorsToteProb to be at least 0.95 before you open your wallet. Consider keying in something like "EB 0.95" (without the quotes) into the BettingInstructions field. You'll see it on the HTML Report and in the Live Play Module... Allowing you to ACT without hesitation. -jp . ~Edited by: jeff on: 9/23/2009 at: 9:18:05 PM~
| |
| JustRalph 9/24/2009 4:25:15 AM | Jeff I have over 90 UDM's ....... I have to re-write all of these in SQL ?
| |
| jeff 9/24/2009 5:56:38 AM | Are all 90 relevant to you? If not - maybe it's time to pare them down. If they ARE relevant (and you'd rather not spend the time to create SQL counterparts)... Then why not keep all 90... and on race day continue to run your Calc Races routines in Playlist File Mode? However, that doesn't mean you can't run in SQL Mode when it's to your advantage to do so... Suppose you want to do R&D to come up with new UDMs: Why not Run a Data Window Export to the StarterHistory Table... and then flip the Data Window into SQL Mode and do your new R&D that way? It's faster... MUCH faster. But when it comes time to capture ideas from your R&D as UDMs - use the UDM Wizard to create new UDMs as Playlist File UDMs... which will "fire" on race day when you run a Calc Races in Playlist File Mode. Understand, no one is forcing you to do anything. You can run the program in Playlist File Mode for as long as you see fit. And flip to SQL mode (or not) whenever you see fit as well. SQL Mode is all about giving you a way to work faster. -jp .
| |
| JustRalph 9/24/2009 11:38:20 AM | ok.........still playing around here ~Edited by: JustRalph on: 9/24/2009 at: 11:38:20 AM~
| |
| TomV 9/27/2009 1:43:34 PM | Hi, Looked but couldn't locate this factor as part of the StarterHistory Schema nor as one of the 35 factors to add: FimsInLastFour Can that be used in an SQL UDM ?
| |
| jeff 9/27/2009 2:16:28 PM | Currently - No. There are only 255 fields available in the StarterHistory table. If fimsInLastFour goes in then something else has to come out. What I could do... Is add FIMSINLASTFOUR to the "grabbable" factors list so that you could use it (behavior = 3 translate) as one of your UserFactors. That would be easy enough for ME to do... Then it comes down to the question of whether or not FIMSINLASTFOUR is important enough to you to base one of your UserFactors on it... and from there put that UserFactor into one of your 35 F-Slots. One other thought that may get you some mileage... PScore uses FIMSINLASTFOUR as part of it's factor mix - so the two share a loose correlation. Depending on the makeup of the rest of the factors in your UDM... you MAY be able to use PScore in the same UDM in place of FIMSLASTFOUR to good effect... just a thought. Hope I explained that in a way that makes sense. -jp .
| |
| TomV 9/28/2009 1:21:16 AM | Hi Jeff, Did try using Pscore in the UDM vice FIMSINLASTFOUR but its not quite as effective. I still need to go through quite a few UDM's and convert them to SQL , so at this point its probably best to see if any other factors are being used that aren't available. Once the UDM conversion is complete then I will have a better idea of what is most important. For now I can run it in Playlist mode.
| |
| busseb 9/28/2009 5:22:25 PM | Since there is a lot of talk about getting more factors in above the 255, how about another bump on getting the USERFACTORS increased from 5 to 15? Isn't the logic all the same and already done? It would sure help me out ALOT!!! ElPaso
| |
| jeff 9/29/2009 1:19:48 AM | I'm not against adding more UserFactors at some future point - but certainly and absolutely not now. For the immediate future, I am fully committed to some very targeted very specific goals. First and foremost among those goals is making JCapper fully SQL enabled. That extends to build database routines, a faster calc races routine, a much more robust interface for creating a custom html report, routines that allow direct importing of StarterHistory table, html report layout, sample summary, CXN export, and track profile export data from one JCapper2.mdb file to another, and something that I mentioned in the private area of the site: Routines for building a database in (for lack of a better term) UPR Mode... Where the only thing that changes in the history table during the build database process are the values, ranks, and gaps for UserFactors and UPR... Allowing much faster discovery of the effect - good or bad - that recent user edits/IV Table entries have had on UserFactors and UPR. ElPaso, 5 UserFactors are going to have to be enough for now. There are only so many hours in a day. Speaking of hours... I'll be driving across the desert to AZ on Tues 9/29. That means out of the "office" so far as email service goes. Can't guarantee what rural cell phone service will be like - if you have some emergency - call - if nothing else you can at least let me know about it. -jp .
| |
| busseb 9/30/2009 5:47:37 PM | I was hoping that since the logic and programming are already done that it would only be a cut and paste job to do the extra USERFACTORS and that it would only take a minimal amount of time. USERFACTOR development is the most important function in JCapper (as you know by your development of JPR). Having several more USERFACTOR slots available would give us the ability to spend our time on developing more specific USERFACTORS while you are completing the SQL development. Instead of just sitting here waiting, working on new USERFACTORS helps kill time until you finish the next upgrade. Hopefully, we'd both hit the finish line about the same time and we'd be ready to maximize what you have worked so hard to create. It would be like having two Christmas' this year. Oh, well. Thanks for the consideration. ElPaso
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |