Designing tables

In many types of integrations, you’ll want to associate records in your application with records in the accounting system. For instance, you may want to track additional contact information for a customer record in a third-party table. To do this, you could create a table that includes new fields you’ve created in your development dictionary, as well as one or more of the RM_Customer_MSTR table’s key values.

[spacer]

Using the key values from the customer record, you can retrieve the corresponding contacts record. This is especially important when Microsoft Dynamics GP performs actions with the customer record (such as deleting the record or creating a new one), and you want to perform similar actions to the corresponding customer contact record. This is necessary to maintain referential integrity between a third-party record and a related record in the accounting system. Object triggers provide the best means for implementing referential integrity in your application.

Using object triggers

Database triggers are the most reliable method of ensuring referential integrity between third-party records and related Microsoft Dynamics GP records. These triggers respond to successful database operations performed on the core application’s table, such as saving, updating or deleting a record. In response to the trigger, you can save, update or delete a corresponding record in your application. Refer to Object Triggers, for more information about using triggers in your application.

Example: Deleting a record using a database trigger

In this example, the database trigger runs whenever the user deletes a customer record from the RM_Customer_MSTR table (using the RM_Customer_Maintenance form). The following script registers this trigger.

{Name: Startup}
local integer l_result;

l_result = Trigger_RegisterDatabase(reference(table RM_Customer_MSTR), form RM_Customer_Maintenance, TRIGGER_ON_DB_DELETE, script IG_Trigger_Delete_Contact_History);
if l_result <> SY_NOERR then
	warning "Database trigger registration failed.";
end if;

When the delete operation occurs, the trigger passes the contents of the deleted table buffer as an inout parameter to the trigger processing procedure, as shown below. The trigger processing procedure then sets key values from the RM_Customer_MSTR table buffer and deletes the contact history record that corresponds to the deleted RM_Customer_MSTR record.

{Name: IG_Trigger_Delete_Contact_History}
inout table RM_Customer_MSTR;

'Customer Number' of table IG_Contact_History_MSTR = 'Customer Number' of table RM_Customer_MSTR;
release table IG_Contact_History_MSTR;
change table IG_Contact_History_MSTR by number 1;
if err() = OKAY then
	remove table IG_Contact_History_MSTR;
	if isopen(form IG_Contact_History) then
		clear form IG_Contact_History;
	end if;
end if;


Documentation Feedback