Hi everyone,
Firstly, I realise this is an old subject, but I still can't find any easy
answer.
Really, the question is simple: Is there ANY way of TSQLQuery NOT reading
the entire result set into memory?
This is really killing me. I've got quite a lot of web code using sqldb and
it wor
On Fri, 24 Mar 2017, Gary Doades wrote:
>
>> Really, the question is simple: Is there ANY way of TSQLQuery NOT
>> reading the entire result set into memory?
> Set Unidirectional to True, and it will keep only 1 row in memory.
> When you are simply scanning through the re
>
> MSEgui has TSQLResult for that purpose without the TDataset overhead.
> https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/db/msesqlresult.pas
Thanks.
Although it looks interesting I'd rather not get into another set of classes
etc. at this point. I may come back to it la
>> I had read about UniDirectional and I have indeed tried this. It doesn't
>> seem to make any significant difference. Looking through the source code for
>> TBufDataset it looks like UniDirectional just turns off building various
>> indexes/structures etc. and fetches the result set all in one
> From your original message one could think that you were using
> PacketRecords:=-1 which means fetch all records at once, but if you are using
> the standard setting, which is 10 and yet it is still fetching everything at
> once, it
> sounds like a bug to me.
As far as I can tell setting Uni
>
>> It may be that UniDirectional is meant to not buffer all rows, but at the
>> moment it certainly seems to.
> Strange, looking at source code it seems to me, that buffering should not
> happen.
> As far as TUniDirectionalBufIndex should be used and his AddRecord method
> does not allocate n
>
>> Indeed, that's why I can't currently see where the problem lies. It
>> shouldn't buffer the rows/records, but it does... or at least
>> something does and I'm pretty sure it's not my program.
> The DB-client library maybe?
Yup!
I was running some other tests and copied the table contents
On Mon, 27 Mar 2017, Gary Doades wrote:
>> The problem therefore lies in either the Pascal layer on top of the native
>> client libs or in the way the client libs themselves work :( I suspect the
>> latter.
> As far as I know, the DB-Specific pascal layer does not buffer
> I would offer the following definitions:
> - Parallelism is a (design) concept for expressing collateral actions in
> which the processing order of the actions is unspecified. They may take place
> serially or
> contemporaneously in real time, or a mixture of the two.
> - Threads are an impl
>> On Mar 31, 2017, at 5:32 PM, Michael Schnell wrote:
>>
>> Regarding the view of the application (disregarding execution speed) or of
>> the application programmer, there is no difference between real ("Hardware")
>> and virtual (e.g. threads) parallelism. These dirty basics need to be
>>
Windows represents exception codes as an unsigned int. The error -1073741819 is
actually0xC005.
This represents some form of access violation, usually associated with
trying to write to freed memory,double freeing memory etc. If the stack
is involved/corrupted then a trackback and useful i
11 matches
Mail list logo
