COMMUNITY FORUM

Are there any plans to build cascading delete functionality into the Extender module/tables? Situation: When a user adds Extender data to a record (for instance, a Payables Transaction) and then, for whatever reason, deletes the transaction, the Extender data is now orphaned. Problem: Sometimes, when GP re-uses an INV number or something (there is a workaround/setting for this inside GP, but let\’s say it happens from time to time) it associates the old extender data with the new GP record.Current work-around (periodic maintenance):[code]– Display orphans SELECT * FROM dbo.EXT01100WHERE CASEWHEN LEFT(Extender_Key_Values_1, 3)=\’INV\’ THEN Extender_Key_Values_1ELSE Extender_Key_Values_2END   NOT IN (SELECT DISTINCT q1.POPRCTNMFROM (SELECT POPRCTNM FROM POP10300UNIONSELECT POPRCTNM FROM POP30300UNIONSELECT POPRCTNM FROM POP10330UNIONSELECT POPRCTNM FROM POP30330UNIONSELECT POPRCTNM FROM POP10390UNIONSELECT POPRCTNM FROM POP30390)q1)[/code]Then, delete those orphans. *This table is the LAST to be deleted from because all of the other related data in the other tables must be deleted first*The issue with the above maintenance process is that when new extender windows are created, the maintenance process must be updated to include the new window/form references. Requested solution:1) Create cascading delete in the EXT01100 and EXT01200 tables on foreign key – or maybe new tables in a future build2) Implement triggers on the Work/Open/History tables (though, history should NEVER be deleted) to delete from the Window Records (EXT01100) and Forms Records (EXT01200) table when a parent record is deleted**As a note to anyone who wants to use this to build a maintenance script, deleting the record from the EXT01100 table may prevent it from being displayed in the GP window, but it leaves the actual STRGA255, DATE and other related data orphaned.**