Hi Gimmy,
I know I'm advising the obvious, but whenever there are such large number of rows retrieved you really should sit down and ask whether all this data needs to come down into the client app at all.
Im not aware on any limitation in terms of number of rows you can retrieve. Of course, if you store a counter, be sure it is not a smallint :-)
In terms of memory, 3M rows times, for example, a rather simple record - say 100 bytes - makes 300 MB of (heap) memory occupancy, which AFAIK is the only limitation that you may hit.
But maybe your record is 1KB so you go up to 3GB. Since PB IDE is a 32-bit program, the size of dynamically allocated memory is restricted to 2GB... and boom!
You got my point, do some calculation and asses if your memory and network bandwidth can sustain the data volume: to this extent, also open the task manager and monitor your PB IDE or EXE while the DW is being filled.
Also, try to compile the app in 64bit mode and run it, then you can allocate some TBs and any memory limitation is meant to disappear.
Oh, btw, any better with a "retrieve as needed" option?
Last and FWIW, since kernelbase.dll is a Windows system file, you can run SFC from command line and do a system file check to scan for, and eventually restore, corruptions.
Best,
.m
This means that if i enable the option: 'Retrieve options-Rows to disk', i exceed the problem of RaAM?
ty
Gimmy