Some reports we are developing require an awfull lot of data. What i would like is to use LLBLGen like a datareader as in the following pseudocode in order to avoid loading the whole set of data into memory.

while (llblGenReader.read(someEntity))
{
     perc = 100* (someEntity.X / someEntity.Y);
    ...
}

Is this possible, or do i have to revert back to a standard Sql DataReader?

Hi,

Correct me if i'm wrong, but if you just don't want to fetch all rows in a table, you just have to specify the number of rows as a parameter of Adapter.FetchEntityCollection() (if you use adapter)

An other idea : LlblGenProDataSource fully supports paging.

Cheers,

Aurélien

You can also fetch a datareader using llblgen pro and traverse the rows using that reader. Very low level, but it could work.

It indeed can be helpful if hte set is really large so you avoid having to fetch everything in memory first.

Another way is to formulate a scalar query which is ran on the DB.

Otis wrote:

You can also fetch a datareader using llblgen pro and traverse the rows using that reader. Very low level, but it could work.

It indeed can be helpful if hte set is really large so you avoid having to fetch everything in memory first.

Can you give a little more info on how to do that. I am still using the 1.0 version, adapter-scenario. I've also seen some threads on this forum saying that exposing a datareader is not such a good idea.

wvnoort wrote:

Otis wrote:

You can also fetch a datareader using llblgen pro and traverse the rows using that reader. Very low level, but it could work.

It indeed can be helpful if hte set is really large so you avoid having to fetch everything in memory first.

Can you give a little more info on how to do that. I am still using the 1.0 version, adapter-scenario. I've also seen some threads on this forum saying that exposing a datareader is not such a good idea.

Fetching a datareader is a v2.0 feature. In v1.0, fetching a datareader can be a bit of a challenge, but not impossible. What you can do is create a RetrievalQuery using the adapter's CreateSelectDQ method (so you have to add some code to a derived class of the dataaccessadapter) and be sure you pass in persistence info as well, so you should for example pass into your own method an EntityFields2 object, of which you obtain the persistence info for using similar code as FetchTypedList() (see ormsupportclasses sourcecode).

A RetrievalQuery object has an Execute method which returns an IDataReader. You can then do whatever you want with it. Check also ExecuteMultiRowDataTableRetrievalQuery to see how to open a connection and map a transaction (if in progress) into the RetrievalQuery.

If you pass in a filter, be sure to grab the persistence info for that as well. You can basicly re-use the code in FetchTypedList and instead of calling the Execute... routine you insert the connection and execute the retrievalquery.

One thing to note is that if you dispose the query or reader in that routine, it won't work on most db's as that will close the underlying reader in most providers. (not on odp.net oracle and sqlserver)

Passing around a datareader isn't that great if you pass it across tiers. Keep your code close to the code which opens the reader as a reader is an open db connection.

Thanks a lot. That was the info i needed.