Transferring data from one QAD to another without losing integrity
Often during QAD system upgrades there is a need to transfer transactional or static data from one QAD database to another. Typically, companies spend effort to get the required data into pre-production database. To save the effort, specifically when this should be done many times in the row, QAD customers want to transfer the data, versus re-entering them each time they refresh pre-production DB.
Unlike CIM’ing the data, transferring is far more efficient and quick. However, if not done right, you may cause the data integrity along the way. That’s why it’s not recommended by QAD and many consultants would reject this option too. But when the system downtime is your constrain, and you can afford proper planning and testing the solution, the answer is – yes, it’s doable.
We have done this many times in different projects, transferring and merging data from different databases into another ones. By learning this principle, you also can do this yourself, provided you have sufficient technical knowledge and experience in QAD ERP app.
The benefits of this approach are obvious. For instance, within 2 day downtime window you can upgrade QAD system from one version to another with the complete change of chart of GL Accounts. Or transfer SKU’s, customers and open orders, quotes from one DB to another, etc..
Typically QAD *.23 menu programs, Delete/Archive utilities, are open source programs and you can locate them in $QAD/src directory. Go over the code logic and take a note how records of main tables relate to records in associated QAD tables. Replace record deletion statements with record creation statements (see below).
Create and use a new progress client script, which will connect to two QAD databases at once. Source DB and Target DB. Use the logic above to create records in the target DB (instead of deleting the records), using the data from source DB.
This exercise should be well planned and well tested afterwords, by functional consultants or end users.
You will have to have and run test scripts to make sure the new transferred data are usable and not causing any problems later in the business cycle. This is really important step. Once working, you can execute these scripts as many times as you like and the time it takes is really a few minutes even for large amounts of data. Unlike CIM or manual entry. Good luck!
