Thanks Dino,
I just converted to Use instead of Store and it looks like that fixed
the issue.
Evidently, 90K rows with 4 fields each is too big. WAY too big. If not
for memory, then for efficiency of the destructor.
Thanks again,
Paul
On 3/23/2011 9:41 AM, Dino Korah wrote:
> "Use" is always better than "Store" method for big result sets.
> So if this change makes no difference to rest of your application,
> this must be the one that you try first.
>
> You can always profile and debug your "Store" based solution, but it
> will be of academic value (very likely).
>
> Bests,
> Dino
>
>
> On 23/03/11 14:21, Paul Dalach wrote:
>> Hi all,
>> Thanks for any responses.
>>
>> The max memory a typical query requires under 100mb...well within my
>> 10gb memory limit.
>>
>> I have tried both debug and release libraries and get the same issue
>> with both.
>>
>> I am trying now to profile the application to find out precisely where
>> the hangup is...any suggestions would be welcome.
>>
>> Any other thoughts? Should I switch to use instead of query?
>>
>> Paul
>>
>>
>> On 3/23/2011 7:26 AM, Tomalak Geret'kal wrote:
>>> On 23/03/2011 12:22, Joel Fielder wrote:
>>>> Hi all,
>>>>
>>>> This isn't aimed at anyone in particular, but the past
>>>> couple of days have had topics turn into a discussion about
>>>> other stuff.
>>>>
>>>> It would really help if posters would add OT to the subject,
>>>> or specify a new subject if this happens.
>>>>
>>>> I call this rule "try before you buy" - we all have lots of
>>>> email and good email subjects really make a difference to
>>>> whether I read or delete :)
>>>>
>>>> Anybody got any comments or thoughts? Or am I being high
>>>> maintenance?
>>>>
>>>> Joel
>>>>
>>> No, I think you're absolutely right.
>>>
>>> The most recent thread in particular has now gone away from the scope
>>> of StoreQueryResults.
>>>
>>> I'm hesitant to comment more on the matter seeing as my suggestion to
>>> add a subject line prefix to list mails was shot down so
>>> vehemently... :P
>>>
>>> Tom
>>>
>>
>
