Hoping Kyle sees this, since he provided the initial feedback to this problem the first time it came up. A few months ago (~Sep 9) I was told I had an issue with a method I was using to grab a PrgCtx for a KIni lookup when a PrgCtx was not being provided in the function I need the call in. The new function looks like this, in part:
if(!IsDefined(prgCtx) || IsError(prgCtx)) if($Kernel.SystemPreferences.GetPrefBoolean( "DBUPGRADE", "UpgradeInProgress", FALSE )) prgCtx = $CurrentWizAPI.GetPrgCtx() else prgCtx = $WebProspector.Utils.GetPrgCtx() end end
That resolved the problem, which consisted of a database upgrade from u9 to u11 causing the database to be "upgraded" to 1.1.11 instead of 6.1.3.
However, I now have a customer that is running into problems after upgrading the database, when they're trying to update the Physical Objects module. The trace files being produced are coming from the otemail and otemailmanagement modules. Digging around, I found that the PrgCtx objects being used in the trace files are coming from similar "GetPrgCtx" functions found in those modules.
Take a look at OTEMAIL 10.2.3 in OTEMAIL:OTEmail Root:OTEmailUtils.GetPrgCtx. It's somewhat similar to my new GetPrgCtx function.
So here's the kicker--with my updated GetPrgCtx function in place via patch, the core database upgrades fine, but the PO module upgrade fails (the stack trace reports that the prgCtx object is missing a .fDBConnect.fLogin). However, if you upgrade the database with my patch in place, then remove my patch and then upgrade the PO module, it works. I'm at a loss. Can anyone explain this?
