0

We are running a pretty uncommon erp-system of a small it-business which doesn't allow us to modify data in an extensive way. We thought about doing a data update by exporting the data we wanted to change directly from the db and by using Excel VBA to update a bunch of data of different tables. Now we got the data updated in excel which is supposed to be written into the Oracle DB. The it-business support told us not to do so, because of all the triggers running in the background during a regular data update in their program. We are pretty afraid of damaging the db so we are looking for the best way to do the data update without bypassing any trigger. To be more specific there are some thousands of changes we've done in different columns and tables merged all together in one Excel-file. Now we have to be sure to insert the modified data into the db and firing all the triggers the erp-software does during data update.

Is there anyone who knows a good way to do so?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
matt
  • 65
  • 10

2 Answers2

0

I don't know what ERP system you are using, but I can relate some experiences from Oracle's E-Business Suite.

Nowadays, Oracle's ERP includes a robust set of APIs that will allow your custom programs to safely maintain ERP data. For example, if you want to modify a sales order, you use Oracle's API for that purpose and it makes sure all the necessary, related validations and logic are applied.

So, step #1 -- find out if your ERP system offers any APIs to allow you to safely update your data.

Back in the early days of Oracle's ERP, there were not so many APIs. In those days, when we needed to update a lot of table and had no API available, the next approach would be to use some sort of data loader tool. The most popular was, in fact, called "Data Loader". What this would do is read your data from an Excel spreadsheet and send it to the ERP's user interface -- exactly as though it were being typed in by a user. Since the data went through the ERP's UI, all the necessary validations and logic would automatically be applied.

In really extreme cases, when there was no API and DataLoader was, for whatever reason, not practical, it was still sometimes deemed necessary and worth the risk to attempt our own direct update of the ERP tables. This is, in general, risky and a bad practice, but sometimes we do what we must.

In these cases, we would start a database trace going on a user's session as they keyed in a few updates via the ERP's user interface. Then, we would use the trace to figure out what validations and related logic we needed to apply during our custom direct updates. We would also analyze the source code of the ERP system (since we had it available in the case of Oracle's ERP). Then, we would test it extensively. And, after all that, it was still risky and also prone to break after upgrades. But, in general, it worked as a last resort.

Matthew McPeak
  • 17,705
  • 2
  • 27
  • 59
  • I think the problem is, they have already updated their data in Excel. – APC Mar 05 '17 at 16:31
  • @APC - Then I am not understanding the problem. As I understand it, they have an Excel spreadsheet containing the data as they want it to look in the database. They want to get this into the database, but they want to ensure other, ERP-specific logic ("triggers") happens as they update the database. I think my answer addresses that understanding of the problem, with the assumption that not all ERP-specific logic is necessarily implemented in the form of database triggers. – Matthew McPeak Mar 05 '17 at 17:01
0

No my problem is that I need to do the work fast by make some automation in my processes. The work is already done on excel that's true but it needed the modification anyway. It's only if I put it manually with c&p into the db over our ERP or all at once over I don't know what. But I guess Mathew is right. There are validation processes in the ERP so we can't write it directly into the db. I don't know maybe you could contact me if you have a clue to bypass the ERP in a non risky manner.

matt
  • 65
  • 10