If you are using Progress OpenEdge version 10.2 or better you can embed .NET controls directly into a 4GL program. But that would be like swatting a fly with a sledghammer... And even if it wasn t the Progress 4GL (the programming language) is aggressively single-threaded and will not support multi-threaded .NET controls.

Both the 4GL and the SQL-92 db engines (Progress supports 2 different interfaces to the storage engine) are multi-threaded and perfectly happy to take advantage of as many cores as you have.

You may however, have a licensing restriction -- the "work group" license uses a semaphore based concurrency algorithm in v9 and early v10. (Later versions use a very limited mutex (spin lock).) The "enterprise" db has no such restriction.

Or it is possible that the target system simply hasn t been setup to support multiple ODBC connections (the db admin should know, key parameters are -Mn, -Ma and possibly -Mpb).

If I were doing this I think that I would simply fake multi-threaded access by starting multiple sessions against different segments of the data.

It s easier if you use Java+JDBC drivers, from JDBC it s fairly simple to work with the OpenEdge DB.

Not sure about MS-SQL Server but MySQL has a database migration that happily connects to OpenEdge via JDBC and imports selections or all tables for you.

I ve always found the Progress ODBC drivers buggy and troublesome with .NET, I avoid them as much as I can.

You ve also got the app-server to work with, though this is just as bad, it s single threaded and you ll have a limited connection limit for multi-threaded access. If you do choose this option setup stateless services.

I m late but thought it might be useful to suggest something...

You can write your business logic using .NET and plug into your data using the OpenEdge Open Client proxies. If you build a nice boundary (data access) layer around the proxies and the proxies do little more than extract the data that your BL in .NET will use, then at some point you should be able to swap it out. This will be harder if your existing app is huge and chunky which will make it difficult to layer it. This also assumes you are working with Progress Appservers.

If you are not using appservers then you can still write your data access in .NET and wrap it around a set of com-callable wrappers...these can be called directly from your 4GL "client code". In this approach the moving to SQL Server will be a bit harder, but still, it might be moving you in the direction you want.

Good luck!

I know this is a little bit of thread necromancy but if some poor soul is looking for an answer, here s how I did it with CQRS and .NET.

• I wrote Progress commands and queries to perform our data operations.
• The commands and queries were accessed from .NET by calling a Command or Query dispatcher
  • The dispatcher was accessible from the Webspeed server.
  • The dispatcher took the command or query name and form data.
  • Called the Command or Query name and, for the query dispatcher, expected a temp-table handle to be returned.
  • When the query returned the temp-table handle, the query dispatcher wrote the contents of it out as JSON to the webstream.

Once we could consume JSON, the data access became quick and multi-threaded.

At first you should have a look at SQL Server Integration Services when you want to migrate data to a Microsoft SQL Server. If you want to code the transformation rules in .NET, have a look at the Npgsql provider. It even supports the ADO.NET Entity Framework, hence it should be quite easy to develop a migration application.

I am very late with an answer to this question, but if anybody is looking to do this I would head straight for the sqldump utility in openedge. Dumps out the contents of tables directly to text. Very fast. You can also dump out the structure with another tool, so then you could write code to interrogate the structure file, and load data from the text file into your SQL table(s).