RE: [PEAR] Fetching PEAR DB in a set

> From: Sanjay [mailto:sanjay92@hotmail.com] > Sent: Tuesday, December 23, 2003 12:23 AM > To: pear-general@lists.php.net; Graham Clarke > Subject: Re: [PEAR] Fetching PEAR DB in a set > > Thanks Graham, > I have looked PEAR DB manual and also MDB documentation. I have seen > methods > to get one row or all rows. > I know, I can loop thru recordset without any problems but what I am > asking > is different. > 1. Suppose, If I execute a query which returns 1 million records, so I can > do DB_Common::getRow() -- fetch the first row or do DB_Common::getAll() -- > Fetch all rows , how is memory handling, if I do DB_Common::getAll. I > don't know how is memory handled in getAll case . Will it create memory > problems when data is very big. Let me explain a few things: 1.) you probably don't want to fetch 1 million rows into php 2.) some database ext buffer the result rows, some don't, some make it optional. However PEAR::DB uses buffered wherever possible, to allow stuff like numRows() (which requires that the entire result be read to determine the entire number of rows). This means that in those cases all result rows are buffered on the client, so you will always incur the huge memory load of fetching large amounts of data 3.) MDB 1.x always buffers. If not supported by the ext it bufferes internally 4.) MDB 2.x makes this an option > 2. The method which mentioned above, gives fetch 1 row or all rows but > what > I want is to fetch in batches, in oracle terms, it is called array Fetch > or > Bulk Fetch (PLSQL) and I can define how many records, I want to fetch at > one > time so e.g. if I query returns 1000 records and if I say in one fetch > return 100 recors so there will be just 10 trips to fetch all data so my > question is how can I do this in PEAR DB or MDB Well you could make several queries using modifyLimitQuery(). Not sure if that will be a huge step forward. This will be your best bet at creating a solution which will work in DB and MDB 1.x. Note that MDB2 is still heavily under development (I am planning on drastic refactoring over the holidays). So maybe you should consider using native queries for this one. This is of course an option. Regards, Lukas