D
dbeavon
Guest
>>create a SQL server table from a Progress temp-table, then use this SQL table from Excel for report generation. That makes sense; I'm sending data in the opposite direction - from a SQL92 ODBC query back into a Progress temp-table in an ABL session. As a side, you might want to check out SQLite (embedded database that uses a local file) for your scenario too. The nice thing about that approach is the fact that SQLite is in the public domain and there is no server-side infrastructure (which might be somewhat overkill for an Excel report). Excel can pull in the SQLite data quite easily too (or at least that is what I've read, I've familiar with using Excel power pivot, but haven't specifically connected to SQLite via its odbc driver yet). Either approach is a reasonable alternative to buying the full Pro2 product, which might also be a way to solve the problem while avoiding the need for a programmer. >> generate a .p file on the fly with the basic FOR EACH and assignment statements and then run the newly generated .p. In my case, I will extrapolate that the generated .p FOR EACH would look a lot like your SqlDataReader (SQLDemo1). Even as a generated .p it will be quite slow because of all the interop going on between ABL's CLR-bridge and the OdbcDataReader. Whereas a FOR EACH that uses a simple IMPORT statement is quite fast (as long as the data file has been written properly to a file). >> necessitated by the need to massage some Progress data types before they go into SQL Since I'm getting OE data out of an OE database (via ODBC) and putting it (eventually) in OE temp tables, there should be no substantial "massaging" (ETL) should be necessary. At least the TT data will be no different than what our ABL code is used to. Thanks for the additional details. Let me know if you have any thoughts about quickly moving SQL92 data from an .Net DataTable into an ABL temp-table.
Continue reading...
Continue reading...