Fun/Weird Bugfix for 12.0 or later -- dupe pkg rows in order hist/search

I just spent 25 minutes figuring out a weird behavior in my database, and thought I'd post my findings.

The behavior to look for is duplicate rows in order search or constituent record/orders tab where the first product is a package.

I discovered that this was ultimately related to reported defect 63194 (fixed in 12.5, but present at least from 12.1 onward), wherein editing a prod season and saving in a manner that kept the detail window open would switch the prod season to the zero inventory. If you don't notice that this has happened when you are editing your ticketing setup, it is possible to attach keywords, content, ticket text, etc to the Zero Inventory.

If the user happens to then change the season for the zero inventory from the System Default Season (id 0) and save, then this new season value is written to the T_PERF and T_PROD_SEASON tables.

Finally, this nonzero value for T_PERF.season where perf_no = 0 causes incorrect behavior of VS_PERF (two zero perf rows) which causes joins in the order search procedures to duplicate package orders.

You can check if you've been bitten by this with a simple SELECT season FROM [ T_PERF | T_PROD_SEASON ] where prod_season_no = 0 -- and fix it by updating that value to zero if its anything other than zero. Even if you don't find anything there, it's also a pretty good idea to inspect your inventory TX tables for prod season 0 if you've been on version 12 (pre-12.5) for any length of time and had people configure seasons on it--I'll bet you find some random keywords or content types.

Parents
  • Hi Nick,

    Thanks for posting this - I wasn't going crazy! We have the same issue and it's affecting a number of reports. I wasn't sure if simply overriding the erroneous numbers would work right off the bat, but following your advice I changed the values and will report here if any problems still persist.

    best wishes,

    Mike

Reply
  • Hi Nick,

    Thanks for posting this - I wasn't going crazy! We have the same issue and it's affecting a number of reports. I wasn't sure if simply overriding the erroneous numbers would work right off the bat, but following your advice I changed the values and will report here if any problems still persist.

    best wishes,

    Mike

Children
No Data