moving data out of Progress

Posted by Admin on 17-Jun-2008 15:42

I have my progress database and I would like to move 11 tables into a MS SQL 2005 database. Is there a recommended method to get that done? I tried DTS but that is on the slow side

All Replies

Posted by Admin on 19-Jun-2008 14:06

Has anybody had any success with moving "x" amount of data out of progress in SQL Server on a regular basis? How was it accomplished?

Posted by Thomas Mercer-Hursh on 19-Jun-2008 14:25

I have heard of people doing that sort of thing based on the idea that it took reporting load off of the production database, but I have a lot more examples of people who successfully do their reporting out of the production database and thus avoid any replication issues and have completely up to date information.

Don't leap too quickly in this direction until you understand why you are having the issues with direct access.

Posted by Admin on 19-Jun-2008 16:22

I agree. I might have a database problem that needs to be fixed no matter what. At the same time running reports on another server would be a nice thing. I probably need to fix the database problem first anyway because I can't get the data out in a timely manner over an ODBC connection.

Posted by Thomas Mercer-Hursh on 19-Jun-2008 16:37

If your production database is stretched to the max and it is not possible to give it more resources and the reporting is heavy, then there are good arguments for offloading reporting to another server. But, it also raises issues in terms of how current the data are and whether or not the copy of the data is full and accurate. Consequently, most of the time I recommend reporting on the production server. If you have some kind of report server setup, it is fine to put the actual report server on another box so that the report generation is being done elsewhere, but pull the data from the production database unless there is a good reason not to.

Posted by jtownsen on 23-Jun-2008 12:58

ODBC is renown for being slow. In addition to being slow, it's always a client-server connection to the database. If I had to regularly push serious amounts of data from one database to another, I'd look using:

- OpenEdge Replication (was specifically designed for having a separate DB for reporting)

- A real-time (or near real-time) messaging based solution - distributes the load throughout the day

- an ABL program running in shared memory against the database that dumps to a local file (then FTP & import)

Posted by Tim Kuehn on 23-Jun-2008 13:19

If the objective is to report on only a few tables, it wouldn't be too hard to implement a trigger-based replication system which would apply the table updates to another PSC db / table.

This thread is closed