UPDATE: Found the fix
Issue:
An error when posting a check batch occurred with minimal information (Bad Datatype detected for operation)
Steps that lead to resolution:
• Run SQL trace while user tried to post – no actionable data retrieved
• Had user turn on manual logging and built a dexlog file set to review
o Actionable data: 'Post_PM_Batch_Recovery', table 'Batch_Headers', 0, "Bad Datatype detected for operation", "Computer Checks", 2, 0-
• I Googled the actionable data and found that the issue is often associated with Extender Table Links
o www.eonesolutions.com/.../
Interim Resolution:
• Disabled/removed all of the Extender Table Links which allowed the batch to post successfully
Understanding what’s going on:
“Table Links” tell Extender “When a record is deleted from Table X, look in these tables to find the record.” Table Links are not necessary, but are nice to have for housekeeping processes since we can put a boat-load of data into Extender fields.
In the past, I've had issues where a person would put in a transaction and it would already have Extender information associated with it. This was caused by two things 1) GP would tend to re-use old, previously deleted INV and VCH numbers and 2) when those transactions were deleted, the Extender data would be left orphaned out there. We “fixed” issue 1 by modifying a setting in GP to never re-use * numbers. This works about 99.9% of the time. We “fixed” issue 2 by setting up Table Links in the Extender windows.
However, the addition of some new fields in an existing Extender Window created a break/fix situation where the Table Links process failed to work properly, thus giving the Bad Datatype error.
Proposed permanent solution:
We have restored the “broken” [company] database into [test company] database so we can work through the Table Links and figure out which link or field specifically is creating the issue and resolve that.
Share
Report
30
All responses (
Answers (
