Subject | Strange bug? |
---|---|
Author | lcampbell |
Post date | 2012-10-17T17:41:25Z |
I'm working with IBO4.9, under Delphi2010 with Firebird 2.5.1.
I set up a TIBOQuery with the following SQL:
/select//
// cts.CT_SPID, //
// (select sa.AD_SIZE from SPONSORSHIPADSIZES sa//
// where sa.AUCTIONID = :SelA and//
// sa.AD_SIZEID = csa.AD_SIZEID) AdSzName, csa.*//
//from//
// CT_SPONSORSHIPS cts//
//join//
// CT_SPONSORSHIP_ADS csa//
//on//
// cts.AUCTIONID = csa.AUCTIONID and//
// cts.CT_SPID = csa.CT_SPID//
//where//
// cts.AUCTIONID = :SelA and//
// cts.SPONSORSHIP_LEVELID = :SelID/
When I test it in DB Workbench, or in the Delphi IDE (by making it
Active), it works, no problem. However, when it runs inside the Delphi
app that uses it (along with several hundred other TIBOQueries); it
literally "blows up my database connection (for which I'm using a
TIBODatabase). The error message says "lost connection to the server"
with my computer name (on which the Firebird server is located). What's
more, after it blows up in my application, the connection is also blown
in DB Workbench and in the Delphi IDE. I can recover by disconnecting DB
Workbench and reconnecting; and by closing out the Delphi Application
and re-opening it. Then, once again, the query works in the development
environment(s).
NOW, here's the zinger. When I remove the subquery, and instead make it
a 3-join query (see below), it works!
/select//
// cts.CT_SPID, sa.AD_SIZE, csa.*//
//from//
// CT_SPONSORSHIPS cts//
//join//
// CT_SPONSORSHIP_ADS csa//
//on//
// cts.AUCTIONID = csa.AUCTIONID and//
// cts.CT_SPID = csa.CT_SPID//
//join//
// SPONSORSHIPADSIZES sa//
//on//
// sa.AUCTIONID = csa.AUCTIONID and//
// sa.AD_SIZEID = csa.AD_SIZEID//
//where//
// cts.AUCTIONID = :SelA and//
// cts.SPONSORSHIP_LEVELID = :SelID//
/
I'm not sure if this is a bug in Delphi, IBO, Firebird, or something
latent in the rest of my application. It would seem that it happens
while IBO is attempting to parse my SQL with the subquery in it. (???)
It's just plain weird.
Thanks for any insight,
Lane Campbell
NW Software**
[Non-text portions of this message have been removed]
I set up a TIBOQuery with the following SQL:
/select//
// cts.CT_SPID, //
// (select sa.AD_SIZE from SPONSORSHIPADSIZES sa//
// where sa.AUCTIONID = :SelA and//
// sa.AD_SIZEID = csa.AD_SIZEID) AdSzName, csa.*//
//from//
// CT_SPONSORSHIPS cts//
//join//
// CT_SPONSORSHIP_ADS csa//
//on//
// cts.AUCTIONID = csa.AUCTIONID and//
// cts.CT_SPID = csa.CT_SPID//
//where//
// cts.AUCTIONID = :SelA and//
// cts.SPONSORSHIP_LEVELID = :SelID/
When I test it in DB Workbench, or in the Delphi IDE (by making it
Active), it works, no problem. However, when it runs inside the Delphi
app that uses it (along with several hundred other TIBOQueries); it
literally "blows up my database connection (for which I'm using a
TIBODatabase). The error message says "lost connection to the server"
with my computer name (on which the Firebird server is located). What's
more, after it blows up in my application, the connection is also blown
in DB Workbench and in the Delphi IDE. I can recover by disconnecting DB
Workbench and reconnecting; and by closing out the Delphi Application
and re-opening it. Then, once again, the query works in the development
environment(s).
NOW, here's the zinger. When I remove the subquery, and instead make it
a 3-join query (see below), it works!
/select//
// cts.CT_SPID, sa.AD_SIZE, csa.*//
//from//
// CT_SPONSORSHIPS cts//
//join//
// CT_SPONSORSHIP_ADS csa//
//on//
// cts.AUCTIONID = csa.AUCTIONID and//
// cts.CT_SPID = csa.CT_SPID//
//join//
// SPONSORSHIPADSIZES sa//
//on//
// sa.AUCTIONID = csa.AUCTIONID and//
// sa.AD_SIZEID = csa.AD_SIZEID//
//where//
// cts.AUCTIONID = :SelA and//
// cts.SPONSORSHIP_LEVELID = :SelID//
/
I'm not sure if this is a bug in Delphi, IBO, Firebird, or something
latent in the rest of my application. It would seem that it happens
while IBO is attempting to parse my SQL with the subquery in it. (???)
It's just plain weird.
Thanks for any insight,
Lane Campbell
NW Software**
[Non-text portions of this message have been removed]