Board index » delphi » Major major MAJOR bug in BDE

Major major MAJOR bug in BDE

I have (unfortunately) discovered a rather severe bug in the Borland Database
Engine.  To be brief: passthrough (RequestLive = TRUE) SQL queries cause a memory
leak in IDQRY01.DLL.

It may be specific to my SQL-LINK (ORACLE) but every TQuery.Open and every Master
Query DataChange in a Master-Detail Query causes a leak of about 5k from the
IDQRY01.DLL memory allocation (for EVERY TQUERY).  After 1700 of these leaks,
IDQRY01.DLL reports an EOutOfMemory exception, and must be unloaded and reloaded
to continue.

1700 sound like a lot?  Not if you have 10 detail queries, like I do.  That's
right kiddies, hit the (Master query TDBNavigator) Prior or Next buttons 170 times
and your program will crash.  And so will Paradox and every other BDE program you
have running.

What did Borland say when I reported it?  "Call our 1-900 line for help."  I am
going to pay Borland to let me help them debug a program I just got done paying
them $1700 for?  How nice of me!

I have been able to reproduce it on every machine I have tried (rather, I haven't
been able to not produce it, which really was the effect I was after.)  You can
watch it too: grab HeapWalker or whatever memory leak de{*word*81} you like to use and
watch IDQRY01.DLL's private allocations: when they reach 8.5 megs watch what
happens.  Neeto!  This is an especially nifty side effect when your project is
due, and Borland won't return your calls.

This can be demonstrated without a single line of code, just slap down two
TQuery's in a Master-Detail relationship, hook a TDBNavigator up to the master
DataSource, make sure the Detail TQuery is set up with RequestLive = TRUE.  Run.  
Hit the Navigator buttons about 1700 times.  (The preferred demo uses a TTimer to
automate the process, but that would require a single line of code ;-)

It does not happen with TTables or Local-SQL TQuerys.  (But I NEED to use
passthrough TQuerys!)

Disgruntled,

        Brian Badger
        MCI Telecommunications

--
Brian Badger, Registered Telepath; P -3 (I can't even read my own thoughts...)
My opinions are my own, and do not reflect the views of the Psi Cop who
implanted my personality.

 

Re:Major major MAJOR bug in BDE


Hi,

Does leak only happen when using the RequestLive property? I am
finding more and more that the RequestLive property, while an
honorable attempt, causes more problems then it solves.

You know... While this is not a particularly acceptable solution, you
could simulate what RequestLive does.

If you did not use the data aware components and instead used a normal
grid, you could move the data in and out of it as you needed to.

Like I said, not an acceptable solution (that is a significant leak in
a highly used area!), but it might get you 'by' for now.

Good Luck,
Allen

Quote
Brian Badger <bbad...@mcimail.com> wrote:
>I have (unfortunately) discovered a rather severe bug in the Borland Database
>Engine.  To be brief: passthrough (RequestLive = TRUE) SQL queries cause a memory
>leak in IDQRY01.DLL.
>It may be specific to my SQL-LINK (ORACLE) but every TQuery.Open and every Master
>Query DataChange in a Master-Detail Query causes a leak of about 5k from the
>IDQRY01.DLL memory allocation (for EVERY TQUERY).  After 1700 of these leaks,
>IDQRY01.DLL reports an EOutOfMemory exception, and must be unloaded and reloaded
>to continue.
>1700 sound like a lot?  Not if you have 10 detail queries, like I do.  That's
>right kiddies, hit the (Master query TDBNavigator) Prior or Next buttons 170 times
>and your program will crash.  And so will Paradox and every other BDE program you
>have running.
>What did Borland say when I reported it?  "Call our 1-900 line for help."  I am
>going to pay Borland to let me help them debug a program I just got done paying
>them $1700 for?  How nice of me!
>I have been able to reproduce it on every machine I have tried (rather, I haven't
>been able to not produce it, which really was the effect I was after.)  You can
>watch it too: grab HeapWalker or whatever memory leak de{*word*81} you like to use and
>watch IDQRY01.DLL's private allocations: when they reach 8.5 megs watch what
>happens.  Neeto!  This is an especially nifty side effect when your project is
>due, and Borland won't return your calls.
>This can be demonstrated without a single line of code, just slap down two
>TQuery's in a Master-Detail relationship, hook a TDBNavigator up to the master
>DataSource, make sure the Detail TQuery is set up with RequestLive = TRUE.  Run.  
>Hit the Navigator buttons about 1700 times.  (The preferred demo uses a TTimer to
>automate the process, but that would require a single line of code ;-)

>It does not happen with TTables or Local-SQL TQuerys.  (But I NEED to use
>passthrough TQuerys!)
>Disgruntled,

>    Brian Badger
>    MCI Telecommunications
>--
>Brian Badger, Registered Telepath; P -3 (I can't even read my own thoughts...)
>My opinions are my own, and do not reflect the views of the Psi Cop who
>implanted my personality.

Re:Major major MAJOR bug in BDE


Brian,

You need the .02 patch...

Dan.
In <30CCC03C.5...@mcimail.com>, Brian Badger <bbad...@mcimail.com> writes:

Quote
>I have (unfortunately) discovered a rather severe bug in the Borland Database
>Engine.  To be brief: passthrough (RequestLive = TRUE) SQL queries cause a memory
>leak in IDQRY01.DLL.

>It may be specific to my SQL-LINK (ORACLE) but every TQuery.Open and every Master
>Query DataChange in a Master-Detail Query causes a leak of about 5k from the
>IDQRY01.DLL memory allocation (for EVERY TQUERY).  After 1700 of these leaks,
>IDQRY01.DLL reports an EOutOfMemory exception, and must be unloaded and reloaded
>to continue.

>1700 sound like a lot?  Not if you have 10 detail queries, like I do.  That's
>right kiddies, hit the (Master query TDBNavigator) Prior or Next buttons 170 times
>and your program will crash.  And so will Paradox and every other BDE program you
>have running.

>What did Borland say when I reported it?  "Call our 1-900 line for help."  I am
>going to pay Borland to let me help them debug a program I just got done paying
>them $1700 for?  How nice of me!

>I have been able to reproduce it on every machine I have tried (rather, I haven't
>been able to not produce it, which really was the effect I was after.)  You can
>watch it too: grab HeapWalker or whatever memory leak de{*word*81} you like to use and
>watch IDQRY01.DLL's private allocations: when they reach 8.5 megs watch what
>happens.  Neeto!  This is an especially nifty side effect when your project is
>due, and Borland won't return your calls.

>This can be demonstrated without a single line of code, just slap down two
>TQuery's in a Master-Detail relationship, hook a TDBNavigator up to the master
>DataSource, make sure the Detail TQuery is set up with RequestLive = TRUE.  Run.  
>Hit the Navigator buttons about 1700 times.  (The preferred demo uses a TTimer to
>automate the process, but that would require a single line of code ;-)

>It does not happen with TTables or Local-SQL TQuerys.  (But I NEED to use
>passthrough TQuerys!)

>Disgruntled,

>    Brian Badger
>    MCI Telecommunications

>--
>Brian Badger, Registered Telepath; P -3 (I can't even read my own thoughts...)
>My opinions are my own, and do not reflect the views of the Psi Cop who
>implanted my personality.

Other Threads