I have a PO import routine that brings in purchase orders. I have encountered our first PO that is causing a primary key violation PK_eConnect_Out_Temp. Out of thousands of POs this one fails due to this violation. I do not see any difference in the PO. Now for this one PO it does already exist in GP but my code is set to update if already exists.The error is occurring on the PO header(taPoHdr).
Hi Richard,
I don't see why it would hurt anything, but you could always just do a backup of the table to be safe.
select * into eConnectOutTempBac from eConnectOutTemp
Then truncate it.
Have a good weekend!
Isaac Olson
Microsoft Support
Isaac, at this point I think what I will do is treat the eConnectOutTemp table as it is intended as a temp table and add a post procedure to clear any records from that table as the PO finishes being imported. Any reason why I simply can't remove all those records right now while no one is in GP? I will issue a truncate table command.
Hi Richard,
I guess I can't see why you would be getting records in the eConnectOutTemp table unless you were actually passing the data through the eConnect Service (or IM or Web Services) or were using requester to pull data from existing POs in GP that you were then updating. Maybe running a SQL trace of your whole process after removing the data from that table, or adding a post proc to clean the data out would be a good idea going forward. It would be difficult to really troubleshoot further through a forums post, but maybe others in the community have had a similar experience and can chime in.
Thanks,
Isaac Olson
Microsoft Support
This is the second thing I have seen that is different when you call the nodes directly. Here is what I am doing.
I am reading PO header and detail information from a custom database. I then pass variables down to a stored procedure to transfer the data in POs in GP.
.
In this stored procedure are calls to taPoLine and taPoHr
I am not calling the eConnect service.
I am getting left over records in the DYNAMICS..SY00800 table and now records in the eConnectOutTemp table
I am not sending any data via XML only as parameters sent to a stored procedure.
Hi Richard,
Normally these would automatically be deleted after the integration goes through successfully from my experience. I did see though in the eConnect Programmers Guild .chm file that if you are using <taRequesterTrxDisabler> that there is a flag for whether or not you want to delete the eConnectOutTemp table when you call this XML.
Element name |
Datatype |
Length |
Required |
Default |
Description |
---|
Delete |
i4 |
2 |
N |
0 |
Flag that specifies whether to delete the record from the eConnectOutTemp table |
That is what I would look into first.
I hope this helps!
Isaac Olson
Microsoft Support
Thanks for your reply Isaac, that is what I thought.
select * from eConnectOutTemp returns 10,215 records. Every PO we have ever imported are listed there. This would explain the duplicate key message but what can I do to get that table to remove the records after each import is completed?
Hello,
When you install the Transaction Requester, the installer creates three tables in each specified Microsoft Dynamics GP database:
The eConnectOutTemp table essentially just hold data temporarily while the transactions are being processed. Let's say that you had an integration fail or ran into an unexpected error, there is a chance that this table might not get cleared out properly. That is when I most often see this error message. If no integrations are currently being processed then I would expect this table to be empty.
select * from eConnectOutTemp
The other thing would be if you accidently included the same PO on the integration twice, (essentially in the same batch of POs that you are importing) I could see that causing an error like this to occur.
I hope this helps!
Isaac Olson
Microsoft Support
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 290,524 Super User 2024 Season 2
Martin Dráb 228,493 Most Valuable Professional
nmaenpaa 101,148