Open Dental Forum

Beta v 17.4.59 - Program is crashing when I try to run Outstanding Ins Report. Looks like there is a pref Name issue? (Linux server)

Unhandled exception from ProgramEntry: OutstandingInsReportDateFilterTab is an invalid pref name.
System.Exception
at OpenDentBusiness.Prefs.GetOne(String prefName) in C:\SVN\beta\OpenDentBusiness\Data Interface\Prefs.cs:line 118
at OpenDentBusiness.Prefs.GetOne(PrefName prefName) in C:\SVN\beta\OpenDentBusiness\Data Interface\Prefs.cs:line 111
at OpenDental.FormRpOutstandingIns.FormRpOutIns_Load(Object sender, EventArgs e) in C:\SVN\beta\OpenDental\Forms Reports\FormRpOutstandingIns.cs:line 891
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Looks like you missed a convert script somehow.
What is the datatype for the GroupNum column on the Insplan table?

SQLyog shows: InsPlan | Columns | GroupNum, varchar (25), Nullable

Thats strange. The code that inserts that is located in the same method and was committed before we released version 17.4.53.
If you self-compile and update it is possible that you missed some of a convert script.
When did you update past version 17.4.53?

If it reached the end of the method/you had the most updated convert script code, then this preference "ClaimPaymentNoShowZeroDate" should be the date you performed the update to 17.4.53, barring any manual changes.

yes, I self compile. 17.4.42 on 3/14/18 @ 11:35AM --> 17.4.52 on 04/11/18 @ 3:47PM, (but maybe it was really some of 17.4.53?) and then the next compile was 17.4.59 4/22/18 @ 2:55PM (as reported by the update window on OD "Help | Update | Show Previous Versions" menu and button)

If you're tired of getting this problem, a workaround would be to always utilize the SVN Update to Revision option instead of the normal Update option and then always choose a revision that has Version X.X.X.X as the commit log. That is an official release commit which would make it so that you aren't at a version prior to it being officially released to the public (which is what caused you to miss the convert script).

Pref.ClaimPaymentNoShowZeroDate = 04/04/2017

ok, yes, I would like to avoid it in the future, so I will see if I can figure out what you mean on SVN then to update to a certain stop point as this did happen to me last year once as well. How should I fix this issue?

The foolproof way would be to use a backup that you have prior to the version with which you are partially upgraded to.
The hard and dangerous way would be to look at each query that gets run in each of our version methods and determine if you need that query to be run or not and then manually run the ones that you deemed were not actually run.

Many of our queries within the convert script make the assumption that you have not been utilizing the version above them AT ALL so the hard and dangerous way mentioned above is still not a 100% guarantee solution for this issue. Reverting to a backup would be the only guarantee. It is ultimately your call on if you are okay with losing and then reentering data OR are you going to roll the dice and see if you can patch your database back up to health.

You (both of you) probably already know this but since you mentioned a Linux server I thought I'd throw it out there that table names are case sensitive in Linux.

I corrected it manually for this one, but yes, Linux is case sensitive and I usually leave my installation as case sensitive rather than turning it off to find errors. This was not a case sensitive issue however, it was compiling non "released" code point and so it skipped a step in the update process later on.