OpenEdge ABLDatareader

[schaapie]

We are trying to get data from a Progress-db into .Net.
I have tried several ways, including ODBC and Appserver.

Now I am wondering if anyone has any experience on this.
The Appserver-solution would use something like the gettemptable.p example sourcecode from Progress.
But I was wondering if passing the data as a temp-table would be the fastest way. That way I is "converted" from abl-datatypes to .Net-datatypes on the way which would take time.
Would a memptr with raw data transfer quicker?
What would be the best way to get the data into the memptr?

Speed is the keyword here.

Any help or thoughts are appreciated
Niek

 

[GregTomkins]

Assuming by .NET you mean MSSQL, I suspect the fastest option would be to dump the Progress data into ASCII, then use MSSQL's bulk load feature to import it. I would expect the loading into target part of the operation to be by far the bottleneck, and, I am pretty sure bulk load is by far the fastest way to do that. This option would also be fairly simple, the only difficulty might be figuring out the exact data format MSSQL requires, but I'm sure Google is loaded with answers to that question.

 

[sdjensen]

Depending on your setup you could also go the 'socket-way'.

Create a progress program that opens a socket port and streams the data and let your .net application connect to this port and receive the data.

 

[schaapie]

To GregTomkins:
No I don't mean a dump from Progress and a load into a SQL-database.
I mean a .Net program using data from a Progress-db.

To sdjensen:
This would be somewhat similar to a statefull appserver call or something? Hmm could be a possibility.

 

[GregTomkins]

Oh sorry, I misunderstood, I guess I am too accustomed to reading about people converting away from Progress...

If you really care about speed I would second the socket suggestion, which would let you bypass the overhead of proxies, temp-table marshalling, name server lookups, etc. That is, you could use sockets without needing any AppServer overhead at all.

Of course, one would hope the data you are sending is simple and not prone to changing. Also, how practical this is depends on whether you are talking about a single, or small fixed number, of .NET clients, as opposed to some variable number that fluctuates a lot and therefore really warrants the overhead of the AppServer broker etc.

I am a bit dubious that the speed benefit is worth the complexity, you will probably find that you are spending 90% of the time on network and database overhead anyway.