Hi David,
There is a pretty decent section in the eConnectProgammersGuide.PDF that should be in the HELP folders of every eConnect install that describes how this table is used.
Here is a diagram but there is more details in the guide. I pulled out what I felt was relevant below.
"eConnect_Out This table stores data from selected create, update, or delete operations that occur within Microsoft Dynamics GP. The data identifies the individual transactions that occurred. The Outgoing Service uses the data in this table to create an XML document that is placed in a queue."
"For example, assume you want your application to be updated when a new customer is added to Microsoft Dynamics GP. To begin, you use the eConnect Requester Setup utility to specify the customer object and the SQL insert operation. The eConnect Requester Setup adds a SQL trigger to the database. When a new customer record is inserted, the SQL trigger creates a record of the event in the eConnect_Out table.
The eConnect Outgoing Service periodically queries the eConnect_Out table. The service uses the record in the table to create an XML document that describes the new customer document.
The Outgoing Service then places the XML document in a message queue where it can be retrieved and used by your application.
To configure the eConnect Transaction Requester, use the eConnect Requester Setup utility. The eConnect Requester Setup utility allows you to specify Dynamics GP objects and operations you want to export to another application. The utility then adds SQL triggers to Dynamics GP that populate the eConnect_Out table for the specified objects and operations. For a detailed explanation of how to use the eConnect Requester Setup utility, see the eConnect Installation and Administration Guide.
Refer to Chapter 17, “Customizing the Transaction Requester,” for information about using and customizing the Transaction Requester Service."
Based on this my guess would be that when this was originally set up for the client, they marked more options than they really needed for tracking changes in GP, and all of these records are captured changes that have been waiting to be picked up by their outside application but never were because they were not needed by the outside application. Now I obviously don't know their whole structure and what they require to tracking changes and what they do not, but based on this, to me these are all just stray records of changes that occurred to documents over the years that they had no need for so they are sitting around waiting to be picked up.
You may want to review chapter 17 in the Programmers Guide next to see what changes they are actually pushing to their outside application, 'if any', and also see if their outside application ever reads this table for any sort of history or reporting on transactions.
To me it would be logical that after passing the changes from GP into the eConnect_Out table, then from the eConnect_Out table to the outside application, that you would want to delete the record, which is why I think these have been piling up for years waiting to be called and never were because the outside applicaiton doesn't need them.
Anyways, I cannot tell you 'Yes' delete them or 'No' keep them because I do feel that answer would be dependent on your environment business processes outside of GP and whether they still need those records, but I hope this information helps you in making your decision easier or at least gives you direction to identify if your outside applications rely on them or not.
Thanks!
Isaac Olson
Microsoft Support
Share
Report
10
All responses (
Answers (
