🚀 go-pugleaf

Mike 

I would suggest trying it with the CursorLocation moved to clUseClient
This may speed you up.


On Wed, 11 Sep 2002 16:55:16 -0400 (EDT), "Mike Ruskai"
<spammoc.reirracten@begoneynnaht.net> wrote:

>On Wed, 11 Sep 2002 11:03:59 -0400, Arnie Mauer wrote:
>
>>"Mike Ruskai" <spammoc.reirracten@begoneynnaht.net> wrote in message
>>news:gunaalargpneevrepbz.h298xv0.pminews@207.105.83.65...
>>> Using BCB6 and ADO (MDAC 2.7) to access data in an Access 2000 database.
>>>
>>> I have found that the Next() function of TADODataSet (or TADOQuery -
>>>doesn't matter) is *extremely* time-consuming.
>
>>Hi Mike,
>>What do you mean by "scroll through".  Is this just a query->Next() ?
>
>Yes.
>
>>When we read a recordset straight through, I use the following params in the
>>TADOQuery:
>>
>>CursorLocarion = clUseServer
>>CursorType = ctOpenForwardOnly
>>CacheSize = 100
>>LockType = ltUnspecified
>>
>>With this setup, I can read 1,000,000 rows from an Oracle server across a
>>100 MBPS LAN in about 20 seconds.  Can you provide any additional info?
>
>I did provide quite a bit more info.  The database is Access 2000 (local
>file).  The cursor cannot be forward only.
>
>Cache size made no difference (tried 1 and 100).
>
>1088 records took 12.45 seconds to scroll through.  The same result set,
>scrolled through with Recordset->MoveNext(), takes less than half a second
>(and that includes reading all fields - over 600 bytes per record - and
>writing them to file).
>
>Because of this huge difference, I went ahead and modified the program to use
>Recordset movement, and added checks for certain calculated field names
>(among other things).  One particular export (of something over 1400
>records), which took over 18 seconds to complete with TADODataSet record
>movement (either First()/Next()/Eof or, even slower, setting RecNo),
>completed in a blink.  I could barely see the status dialog appear before it
>was dismissed.  That's with using Recordset->Move() as well (which allows me
>to loop through a character array which I use to mark records, and only seek
>the records that are to be exported).
>
>I guess I'd have to conclude that the problem is only with the ADO/Access
>combination.  Unfortunately, no other database is suitable for my purposes.