Thread View: borland.public.interbase.sql
33 messages
33 total messages
Started by Massimiliano Trezzi
Wed, 28 May 2008 16:26
no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Wed, 28 May 2008 16:26
Date: Wed, 28 May 2008 16:26
82 lines
3018 bytes
3018 bytes
Hi,
I have a problem with Interbase 2007.
If I make a query with some explicit left outer join (all in from clause)
and some implicit inner join (tables in from clause, conditions in where
clause) I have some chance to get an error: no current record for fetch
operation.
The problem can arise using a view with left outer join in a query with only
implicit joins too.
I agree that is not the best way to make a query, but some tools do so and
this make this trouble a big trouble!
Here are the steps to reproduce the problem:
CREATE TABLE A (
ID INTEGER NOT NULL PRIMARY KEY,
DES VARCHAR(128)
);
COMMIT;
CREATE TABLE B (
ID INTEGER NOT NULL PRIMARY KEY,
A_ID INTEGER,
DES VARCHAR(128)
);
COMMIT;
ALTER TABLE B ADD CONSTRAINT FK_B_A FOREIGN KEY (A_ID) REFERENCES A(ID);
COMMIT;
CREATE TABLE C (
ID INTEGER NOT NULL PRIMARY KEY,
B_ID INTEGER,
DES VARCHAR(128)
);
COMMIT;
ALTER TABLE C ADD CONSTRAINT FK_C_B FOREIGN KEY (B_ID) REFERENCES B(ID);
COMMIT;
COMMIT;
INSERT INTO A (ID, DES) VALUES (1,'A-ONE');
INSERT INTO A (ID, DES) VALUES (2,'A-TWO');
INSERT INTO A (ID, DES) VALUES (3,'A-THREE');
INSERT INTO A (ID, DES) VALUES (4,'A-FOUR');
INSERT INTO A (ID, DES) VALUES (5,'A-FIVE');
INSERT INTO B (ID, DES, A_ID) VALUES (1,'B-ONE',1);
INSERT INTO B (ID, DES, A_ID) VALUES (2,'B-TWO',2);
INSERT INTO B (ID, DES, A_ID) VALUES (3,'B-THREE',3);
INSERT INTO B (ID, DES, A_ID) VALUES (4,'B-FOUR',NULL);
INSERT INTO C (ID, DES, B_ID) VALUES (1,'C-ONE',1);
INSERT INTO C (ID, DES, B_ID) VALUES (2,'C-TWO',2);
INSERT INTO C (ID, DES, B_ID) VALUES (3,'C-THREE',3);
INSERT INTO C (ID, DES, B_ID) VALUES (4,'C-FOUR',4);
COMMIT;
/******************* TEST QUERIES *******************/
/* OK! */
SELECT * FROM C INNER JOIN AB ON C.B_ID = AB.B_ID;
/* NO CURRENT RECORD FOR FETCH OPERATION */
SELECT * FROM A, C LEFT OUTER JOIN B ON B.A_ID = A.ID WHERE C.B_ID = B.ID
/* OK */
SELECT * FROM A LEFT OUTER JOIN B ON B.A_ID = A.ID, C WHERE C.B_ID = B.ID
Thank you in advance.
Massimiliano Trezzi
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Quinn Wildman (CodeGear Develope...
Date: Wed, 28 May 2008 16:52
Date: Wed, 28 May 2008 16:52
100 lines
3505 bytes
3505 bytes
R&D has determined SQL with implicit and explicit joins is bad SQL and therefore is not supported. Massimiliano Trezzi wrote: > Hi, > > I have a problem with Interbase 2007. > > If I make a query with some explicit left outer join (all in from clause) > and some implicit inner join (tables in from clause, conditions in where > clause) I have some chance to get an error: no current record for fetch > operation. > > The problem can arise using a view with left outer join in a query with only > implicit joins too. > > I agree that is not the best way to make a query, but some tools do so and > this make this trouble a big trouble! > > Here are the steps to reproduce the problem: > > CREATE TABLE A ( > ID INTEGER NOT NULL PRIMARY KEY, > DES VARCHAR(128) > ); > > COMMIT; > > CREATE TABLE B ( > ID INTEGER NOT NULL PRIMARY KEY, > A_ID INTEGER, > DES VARCHAR(128) > ); > > COMMIT; > > ALTER TABLE B ADD CONSTRAINT FK_B_A FOREIGN KEY (A_ID) REFERENCES A(ID); > > COMMIT; > > CREATE TABLE C ( > ID INTEGER NOT NULL PRIMARY KEY, > B_ID INTEGER, > DES VARCHAR(128) > ); > > COMMIT; > > ALTER TABLE C ADD CONSTRAINT FK_C_B FOREIGN KEY (B_ID) REFERENCES B(ID); > > COMMIT; > > COMMIT; > > INSERT INTO A (ID, DES) VALUES (1,'A-ONE'); > INSERT INTO A (ID, DES) VALUES (2,'A-TWO'); > INSERT INTO A (ID, DES) VALUES (3,'A-THREE'); > INSERT INTO A (ID, DES) VALUES (4,'A-FOUR'); > INSERT INTO A (ID, DES) VALUES (5,'A-FIVE'); > > INSERT INTO B (ID, DES, A_ID) VALUES (1,'B-ONE',1); > INSERT INTO B (ID, DES, A_ID) VALUES (2,'B-TWO',2); > INSERT INTO B (ID, DES, A_ID) VALUES (3,'B-THREE',3); > INSERT INTO B (ID, DES, A_ID) VALUES (4,'B-FOUR',NULL); > > INSERT INTO C (ID, DES, B_ID) VALUES (1,'C-ONE',1); > INSERT INTO C (ID, DES, B_ID) VALUES (2,'C-TWO',2); > INSERT INTO C (ID, DES, B_ID) VALUES (3,'C-THREE',3); > INSERT INTO C (ID, DES, B_ID) VALUES (4,'C-FOUR',4); > > COMMIT; > > > /******************* TEST QUERIES *******************/ > > /* OK! */ > SELECT * FROM C INNER JOIN AB ON C.B_ID = AB.B_ID; > > /* NO CURRENT RECORD FOR FETCH OPERATION */ > SELECT * FROM A, C LEFT OUTER JOIN B ON B.A_ID = A.ID WHERE C.B_ID = B.ID > > /* OK */ > SELECT * FROM A LEFT OUTER JOIN B ON B.A_ID = A.ID, C WHERE C.B_ID = B.ID > > Thank you in advance. > Massimiliano Trezzi > > > > > > > > > > > > > >
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Wayne Niddery (TeamB)
Date: Thu, 29 May 2008 02:48
Date: Thu, 29 May 2008 02:48
12 lines
1684 bytes
1684 bytes
"Massimiliano Trezzi" <support_leavethis_@intesanet.it> wrote in message news:483d879c$1@newsgroups.borland.com... > > I agree that is not the best way to make a query, but some tools do so and > this make this trouble a big trouble! Any tools that mix the two join syntaxes needs to be fixed or dumped. IMO, *only* explicit SQL-92 join syntax should ever be used. -- Wayne Niddery - TeamB (www.teamb.com) Winwright, Inc. (www.winwright.ca)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Thu, 29 May 2008 06:24
Date: Thu, 29 May 2008 06:24
108 lines
3866 bytes
3866 bytes
Who is R&D? I agree, but this syntax works with most database engines so why a tool producer should fix it? With this choice you give a chance to other db vendor. "Quinn Wildman (CodeGear Developer Support)" <qwildman@nospam.codegear.com> ha scritto nel messaggio news:483d8dff$1@newsgroups.borland.com... > R&D has determined SQL with implicit and explicit joins is bad SQL and > therefore is not supported. > > Massimiliano Trezzi wrote: >> Hi, >> >> I have a problem with Interbase 2007. >> >> If I make a query with some explicit left outer join (all in from clause) >> and some implicit inner join (tables in from clause, conditions in where >> clause) I have some chance to get an error: no current record for fetch >> operation. >> >> The problem can arise using a view with left outer join in a query with >> only implicit joins too. >> >> I agree that is not the best way to make a query, but some tools do so >> and this make this trouble a big trouble! >> >> Here are the steps to reproduce the problem: >> >> CREATE TABLE A ( >> ID INTEGER NOT NULL PRIMARY KEY, >> DES VARCHAR(128) >> ); >> >> COMMIT; >> >> CREATE TABLE B ( >> ID INTEGER NOT NULL PRIMARY KEY, >> A_ID INTEGER, >> DES VARCHAR(128) >> ); >> >> COMMIT; >> >> ALTER TABLE B ADD CONSTRAINT FK_B_A FOREIGN KEY (A_ID) REFERENCES A(ID); >> >> COMMIT; >> >> CREATE TABLE C ( >> ID INTEGER NOT NULL PRIMARY KEY, >> B_ID INTEGER, >> DES VARCHAR(128) >> ); >> >> COMMIT; >> >> ALTER TABLE C ADD CONSTRAINT FK_C_B FOREIGN KEY (B_ID) REFERENCES B(ID); >> >> COMMIT; >> >> COMMIT; >> >> INSERT INTO A (ID, DES) VALUES (1,'A-ONE'); >> INSERT INTO A (ID, DES) VALUES (2,'A-TWO'); >> INSERT INTO A (ID, DES) VALUES (3,'A-THREE'); >> INSERT INTO A (ID, DES) VALUES (4,'A-FOUR'); >> INSERT INTO A (ID, DES) VALUES (5,'A-FIVE'); >> >> INSERT INTO B (ID, DES, A_ID) VALUES (1,'B-ONE',1); >> INSERT INTO B (ID, DES, A_ID) VALUES (2,'B-TWO',2); >> INSERT INTO B (ID, DES, A_ID) VALUES (3,'B-THREE',3); >> INSERT INTO B (ID, DES, A_ID) VALUES (4,'B-FOUR',NULL); >> >> INSERT INTO C (ID, DES, B_ID) VALUES (1,'C-ONE',1); >> INSERT INTO C (ID, DES, B_ID) VALUES (2,'C-TWO',2); >> INSERT INTO C (ID, DES, B_ID) VALUES (3,'C-THREE',3); >> INSERT INTO C (ID, DES, B_ID) VALUES (4,'C-FOUR',4); >> >> COMMIT; >> >> >> /******************* TEST QUERIES *******************/ >> >> /* OK! */ >> SELECT * FROM C INNER JOIN AB ON C.B_ID = AB.B_ID; >> >> /* NO CURRENT RECORD FOR FETCH OPERATION */ >> SELECT * FROM A, C LEFT OUTER JOIN B ON B.A_ID = A.ID WHERE C.B_ID = B.ID >> >> /* OK */ >> SELECT * FROM A LEFT OUTER JOIN B ON B.A_ID = A.ID, C WHERE C.B_ID = B.ID >> >> Thank you in advance. >> Massimiliano Trezzi >> >> >> >> >> >> >> >> >> >> >> >> >>
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Thu, 29 May 2008 06:25
Date: Thu, 29 May 2008 06:25
18 lines
1861 bytes
1861 bytes
I agree, but this syntax works with most database engines so why a tool producer should fix it? With this choice you give one more chance to other db vendor. "Wayne Niddery (TeamB)" <wniddery@chaffaci.on.ca> ha scritto nel messaggio news:483e198f$1@newsgroups.borland.com... > "Massimiliano Trezzi" <support_leavethis_@intesanet.it> wrote in message > news:483d879c$1@newsgroups.borland.com... >> >> I agree that is not the best way to make a query, but some tools do so >> and this make this trouble a big trouble! > > Any tools that mix the two join syntaxes needs to be fixed or dumped. IMO, > *only* explicit SQL-92 join syntax should ever be used. > > -- > Wayne Niddery - TeamB (www.teamb.com) > Winwright, Inc. (www.winwright.ca)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Thu, 29 May 2008 10:14
Date: Thu, 29 May 2008 10:14
25 lines
1963 bytes
1963 bytes
I think this cannot be a justification. What about SQL-92 support? This form of query is not excluded by this specification.. I made a research and I found that this problem is "born" and reported in Interbase 6. This is not the result of an accurate design, but this is a bug: why some mixed queries work and some other not? I think you should fix it. "Wayne Niddery (TeamB)" <wniddery@chaffaci.on.ca> ha scritto nel messaggio news:483e198f$1@newsgroups.borland.com... > "Massimiliano Trezzi" <support_leavethis_@intesanet.it> wrote in message > news:483d879c$1@newsgroups.borland.com... >> >> I agree that is not the best way to make a query, but some tools do so >> and this make this trouble a big trouble! > > Any tools that mix the two join syntaxes needs to be fixed or dumped. IMO, > *only* explicit SQL-92 join syntax should ever be used. > > -- > Wayne Niddery - TeamB (www.teamb.com) > Winwright, Inc. (www.winwright.ca)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Craig Stuntz TeamB
Date: Thu, 29 May 2008 13:33
Date: Thu, 29 May 2008 13:33
18 lines
2049 bytes
2049 bytes
Massimiliano Trezzi wrote: > I agree, but this syntax works with most database engines so why a > tool producer should fix it? Off the top of my head, the best reason that I can think of is that even if it did work, it is likely that performance would be terrible. With an implicit join, the optimizer cannot discriminate well between conscience in the where clause used to filter the completed result set and conscience in the where clause used to specify the join. Garbage in, garbage out. -- Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz Borland newsgroup denizen Sergio Gonz�lez has a new CD of Irish music out, and it's good: http://tinyurl.com/7hgfr
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Thu, 29 May 2008 14:06
Date: Thu, 29 May 2008 14:06
16 lines
1739 bytes
1739 bytes
Massimiliano Trezzi wrote: > I agree, but this syntax works with most database engines so why a > tool producer should fix it? With this choice you give a chance to > other db vendor. I disagree strongly. If you make a list of useful features that R&D could spend their time adding to InterBase support for mixed mode joins would be so far down on the list you could not see it with the Hubble space telescope. The SQL standard was changed to incorporate the new join syntax to allow optimizers to provide better performance. Using the implied join syntax is poor practice because it is likely to give you worse performance than using the SQL-92 syntax. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Thu, 29 May 2008 14:08
Date: Thu, 29 May 2008 14:08
10 lines
1321 bytes
1321 bytes
Massimiliano Trezzi wrote: > This is not the result of an accurate design, but this is a bug: This is not a bug. A bug is something that does not work as designed. The only thing that R&D should do in this case is generate an error and not execute the query. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Quinn Wildman (CodeGear Develope...
Date: Thu, 29 May 2008 14:43
Date: Thu, 29 May 2008 14:43
4 lines
1290 bytes
1290 bytes
Are you looking for names? Massimiliano Trezzi wrote: > Who is R&D?
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: willr
Date: Thu, 29 May 2008 14:59
Date: Thu, 29 May 2008 14:59
17 lines
1538 bytes
1538 bytes
Bill Todd [TeamB] wrote: > Massimiliano Trezzi wrote: > >> This is not the result of an accurate design, but this is a bug: > > This is not a bug. A bug is something that does not work as designed. > The only thing that R&D should do in this case is generate an error and > not execute the query. > R&D = Research and Development. It sounds like generating an error is a good choice. -- Will R PMC Consulting
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Thu, 29 May 2008 16:54
Date: Thu, 29 May 2008 16:54
9 lines
1327 bytes
1327 bytes
Massimiliano Trezzi wrote: > Who is R&D? R&D stands for Research and Development. In this case it refers to the engineers who actually design and write the InterBase code. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Tue, 03 Jun 2008 07:02
Date: Tue, 03 Jun 2008 07:02
41 lines
2605 bytes
2605 bytes
I never wrote manually a query like this, but some _good_ tools do it!
I think this is a bug beacuse:
SQL-92 should accept this syntax: it's bad but it's correct!
all other good databases work with this syntax,
you can have the same problem making a good query with implicit joins
made over some view with explicit outer joins (have I to look inside the
view before building the query?)
In Interbase 5.6 this worked
This is not as designed because:
it happens when fetching records not after parsing the query,
the error is not systematic, but it comes only with outer joins and only
in some circustances
the message is clearly related to some internal code (from sql we do not
manage fetching)
If it was designed as this, I'd expect a message like this "You cannot mix
explicit joins with implicit joins" and it should be systematic.
I hope you understand my bad English, and I hope you understand that
Interbase should be better without this unpredictable behaviour!
Hi,
Massimiliano Trezzi.,
With Delphi I can write ugly code,
"Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio
news:483eb8db$1@newsgroups.borland.com...
> Massimiliano Trezzi wrote:
>
>> This is not the result of an accurate design, but this is a bug:
>
> This is not a bug. A bug is something that does not work as designed.
> The only thing that R&D should do in this case is generate an error and
> not execute the query.
>
> --
> Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Wed, 04 Jun 2008 08:17
Date: Wed, 04 Jun 2008 08:17
26 lines
1971 bytes
1971 bytes
Some "evidences": It's not a workaround, because I'm not sure that it always works, but most of the time I modify the from in this way it works: I put before the "inner joined tables" ordered by number of records descending, then I put the "outer joined tables" ordered by number of records descending chosing left or right join as required by the query itself. I think this can give you a great suggestion about the source of this problem Hi, Massimiliano "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio news:483eb8db$1@newsgroups.borland.com... > Massimiliano Trezzi wrote: > >> This is not the result of an accurate design, but this is a bug: > > This is not a bug. A bug is something that does not work as designed. > The only thing that R&D should do in this case is generate an error and > not execute the query. > > -- > Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Martijn Tonies
Date: Thu, 05 Jun 2008 06:40
Date: Thu, 05 Jun 2008 06:40
49 lines
2865 bytes
2865 bytes
"Massimiliano Trezzi" <support_leavethis_@intesanet.it> wrote in message news:4844ec75$1@newsgroups.borland.com... > I never wrote manually a query like this, but some _good_ tools do it! > > I think this is a bug beacuse: > SQL-92 should accept this syntax: it's bad but it's correct! > all other good databases work with this syntax, > you can have the same problem making a good query with implicit joins > made over some view with explicit outer joins (have I to look inside the > view before building the query?) > In Interbase 5.6 this worked > > This is not as designed because: > it happens when fetching records not after parsing the query, > the error is not systematic, but it comes only with outer joins and only > in some circustances > the message is clearly related to some internal code (from sql we do not > manage fetching) > > If it was designed as this, I'd expect a message like this "You cannot mix > explicit joins with implicit joins" and it should be systematic. Exactly. The current error message is total bogus and doesn't help the user at all. If the error is caused by the mixed join syntax (which shouldn't be a problem at all), then it should be a clear error message. Nevertheless, the syntax IS valid (in SQL 92) and should be supported, after all, it is parsed by InterBase, but not properly executed. This is NOT a user problem, but an InterBase problem. -- Martijn Tonies Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle & MS SQL Server Upscene Productions http://www.upscene.com My thoughts: http://blog.upscene.com/martijn/ Database development questions? Check the forum! http://www.databasedevelopmentforum.com
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Fri, 06 Jun 2008 09:13
Date: Fri, 06 Jun 2008 09:13
22 lines
1834 bytes
1834 bytes
Hi, and now what are you going to do? I think that if you won't fix it, I must know it. I don't pretend you make a service pack for this, but knowing if you'll resolve this for the next service pack or release, it's important. Thank you. Massimiliano Trezzi. "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio news:483eb8db$1@newsgroups.borland.com... > Massimiliano Trezzi wrote: > >> This is not the result of an accurate design, but this is a bug: > > This is not a bug. A bug is something that does not work as designed. > The only thing that R&D should do in this case is generate an error and > not execute the query. > > -- > Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Fri, 06 Jun 2008 14:14
Date: Fri, 06 Jun 2008 14:14
27 lines
2390 bytes
2390 bytes
Massimiliano Trezzi wrote: > and now what are you going to do? > I think that if you won't fix it, I must know it. > I don't pretend you make a service pack for this, but knowing if > you'll resolve this for the next service pack or release, it's > important. I don't understand your question. Quinn Wildman, who is a CodeGear employee, already made the following reply earlier in this thread. "R&D has determined SQL with implicit and explicit joins is bad SQL and therefore is not supported." Therefore, if you are asking if InterBase will be changed to support SQL statements that include both implicit and explicit joins the answer is no. However, you replied to my post in which I said that IB should generate an error and not execute the query. If you are asking if the error message will be added in a future version the answer is that no one knows. If you want that to happen enter a bug report in QC indicating that an error should be returned when a statement includes both implicit and explicit joins and R&D will look at it when they begin fixing bugs in the next version. It is not likely that anyone will make a firm commitment now. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Fri, 06 Jun 2008 16:07
Date: Fri, 06 Jun 2008 16:07
67 lines
3884 bytes
3884 bytes
I'm sorry, but I have to say that I disagree
It's a bug and it's clear that it's not designed to be so.
I include from another post of mine:
> I think this is a bug beacuse:
> SQL-92 should accept this syntax: it's bad but it's correct!
> all other good databases work with this syntax,
> you can have the same problem making a good query with implicit joins
> made over some view with explicit outer joins (have I to look inside the
> view before building the query?)
> In Interbase 5.6 this worked
>
> This is not as designed because:
> it happens when fetching records not after parsing the query,
> the error is not systematic, but it comes only with outer joins and
only
> in some circustances
> the message is clearly related to some internal code (from sql we do
not
> manage fetching)
>
> If it was designed as this, I'd expect a message like this "You cannot
mix
> explicit joins with implicit joins" and it should be systematic.
If you say "we won't fix it because it would be very expensive and we think
it's unimportant" I can say nothing, but I can't accept you say it's not a
bug and you planned so.
I reported the problem in QC, it was promoted to internal database and kept
opened. I'd like to know what it's going to happen to this issue.
Thank you in advance,
Massimiliano Trezzi
"Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio
news:48494656$1@newsgroups.borland.com...
> Massimiliano Trezzi wrote:
>
>> and now what are you going to do?
>> I think that if you won't fix it, I must know it.
>> I don't pretend you make a service pack for this, but knowing if
>> you'll resolve this for the next service pack or release, it's
>> important.
>
> I don't understand your question. Quinn Wildman, who is a CodeGear
> employee, already made the following reply earlier in this thread.
>
> "R&D has determined SQL with implicit and explicit joins is bad SQL and
> therefore is not supported."
>
> Therefore, if you are asking if InterBase will be changed to support
> SQL statements that include both implicit and explicit joins the answer
> is no. However, you replied to my post in which I said that IB should
> generate an error and not execute the query. If you are asking if the
> error message will be added in a future version the answer is that no
> one knows. If you want that to happen enter a bug report in QC
> indicating that an error should be returned when a statement includes
> both implicit and explicit joins and R&D will look at it when they
> begin fixing bugs in the next version. It is not likely that anyone
> will make a firm commitment now.
>
> --
> Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Fri, 06 Jun 2008 17:27
Date: Fri, 06 Jun 2008 17:27
20 lines
2112 bytes
2112 bytes
Massimiliano Trezzi wrote: > It's a bug and it's clear that it's not designed to be so. "As designed" means as designed by the software engineers responsible for the product. It may not work the way you want it to and it may not work the way the SQL standard says it should but, as Quinn stated, it does work the way the R&D team intended. Therefore, this behavior is not a bug. If you disagree with this please look in any dictionary of software engineering terms for the definition of a bug. I certainly agree with you that IB should be changed so that SQL that does not execute correctly either does not execute at all or that it does execute correctly. I do disagree with you in that I think the best fix for IB is to generate an error message and not execute the SQL. There are too many move valuable things that R&D can spend time on to invest their time in making IB support mixed mode joins. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Sat, 07 Jun 2008 08:48
Date: Sat, 07 Jun 2008 08:48
40 lines
2851 bytes
2851 bytes
Hi, Ok, suppose (only suppose) it's not a bug, is it a good thing? If you look all the thread you'll se I'm the only one who thinks so. I can't understand the last sentence: > There are too many move valuable things that R&D can spend time on to > invest their time in making IB support mixed mode joins. I translate it in my own spaghetti English: "We have so many things to work on that we cannot pay attention to this issue" Is it so? Hi, Massimiliano "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio news:48497398@newsgroups.borland.com... > Massimiliano Trezzi wrote: > >> It's a bug and it's clear that it's not designed to be so. > > "As designed" means as designed by the software engineers responsible > for the product. It may not work the way you want it to and it may not > work the way the SQL standard says it should but, as Quinn stated, it > does work the way the R&D team intended. Therefore, this behavior is > not a bug. If you disagree with this please look in any dictionary of > software engineering terms for the definition of a bug. > > I certainly agree with you that IB should be changed so that SQL that > does not execute correctly either does not execute at all or that it > does execute correctly. I do disagree with you in that I think the best > fix for IB is to generate an error message and not execute the SQL. > There are too many move valuable things that R&D can spend time on to > invest their time in making IB support mixed mode joins. > > -- > Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Sat, 07 Jun 2008 09:28
Date: Sat, 07 Jun 2008 09:28
43 lines
3128 bytes
3128 bytes
Hi, it's me again! tell this to your bosses: the problem we have, is that we made a lot of projects with Oracle Hyperion business untelligence suite (the old BrioQuery), and we developed them on Interbase 5.6; now we migrated a lot of our customers to Interbase 2007 and we discovered that these projects don't work because Hyperion generate the queries with implicit joins for inner join and explicit joins for outer ones. I don't think I'm the only one with this problem and I don't think you like have this defect and remember that this syntax is valid in SQL-92. Maybe Oracle could change something in its product, but their database works fine in this context and I think they don't mind of Interbase, because, I repeat, this syntax is standard in SQL-92. Hi, Massimiliano. "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio news:48497398@newsgroups.borland.com... > Massimiliano Trezzi wrote: > >> It's a bug and it's clear that it's not designed to be so. > > "As designed" means as designed by the software engineers responsible > for the product. It may not work the way you want it to and it may not > work the way the SQL standard says it should but, as Quinn stated, it > does work the way the R&D team intended. Therefore, this behavior is > not a bug. If you disagree with this please look in any dictionary of > software engineering terms for the definition of a bug. > > I certainly agree with you that IB should be changed so that SQL that > does not execute correctly either does not execute at all or that it > does execute correctly. I do disagree with you in that I think the best > fix for IB is to generate an error message and not execute the SQL. > There are too many move valuable things that R&D can spend time on to > invest their time in making IB support mixed mode joins. > > -- > Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Martijn Tonies
Date: Mon, 09 Jun 2008 15:20
Date: Mon, 09 Jun 2008 15:20
44 lines
3033 bytes
3033 bytes
> "As designed" means as designed by the software engineers responsible > for the product. It may not work the way you want it to and it may not > work the way the SQL standard says it should but, as Quinn stated, it > does work the way the R&D team intended. Therefore, this behavior is > not a bug. If you disagree with this please look in any dictionary of > software engineering terms for the definition of a bug. Bill, this simply -should- work, or it -should- be rejected with a proper error message. The "no current record for fetch operation" is kinda strange, don't you think? You can get this error when joining with Stored Procedures for example. It's a message that tells the user -absolutely nothing-. Heck, I'm pretty sure this message is NOT raised because of the mixed join syntax, because it's not raised during parsing! It's raised during fetching cause the optimizer generated some execution path that's flawed. If R&D continues to say this mixed join syntax shouldn't work, then they should reject it. > I certainly agree with you that IB should be changed so that SQL that > does not execute correctly either does not execute at all or that it > does execute correctly. I do disagree with you in that I think the best > fix for IB is to generate an error message and not execute the SQL. > There are too many move valuable things that R&D can spend time on to > invest their time in making IB support mixed mode joins. -- Martijn Tonies Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle & MS SQL Server Upscene Productions http://www.upscene.com My thoughts: http://blog.upscene.com/martijn/ Database development questions? Check the forum! http://www.databasedevelopmentforum.com
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Mon, 09 Jun 2008 18:27
Date: Mon, 09 Jun 2008 18:27
9 lines
1441 bytes
1441 bytes
Martijn Tonies wrote: > Bill, this simply -should- work, or it -should- be rejected with a > proper error message. I agree completely. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Tue, 10 Jun 2008 13:07
Date: Tue, 10 Jun 2008 13:07
46 lines
3069 bytes
3069 bytes
Please let me know, did I understand? "Massimiliano Trezzi" <support_leavethis_@intesanet.it> ha scritto nel messaggio news:484a4b69@newsgroups.borland.com... > Hi, > > Ok, suppose (only suppose) it's not a bug, is it a good thing? > If you look all the thread you'll se I'm the only one who thinks so. > > I can't understand the last sentence: >> There are too many move valuable things that R&D can spend time on to >> invest their time in making IB support mixed mode joins. > > I translate it in my own spaghetti English: > "We have so many things to work on that we cannot pay attention to this > issue" > Is it so? > > Hi, > > Massimiliano > > "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio > news:48497398@newsgroups.borland.com... >> Massimiliano Trezzi wrote: >> >>> It's a bug and it's clear that it's not designed to be so. >> >> "As designed" means as designed by the software engineers responsible >> for the product. It may not work the way you want it to and it may not >> work the way the SQL standard says it should but, as Quinn stated, it >> does work the way the R&D team intended. Therefore, this behavior is >> not a bug. If you disagree with this please look in any dictionary of >> software engineering terms for the definition of a bug. >> >> I certainly agree with you that IB should be changed so that SQL that >> does not execute correctly either does not execute at all or that it >> does execute correctly. I do disagree with you in that I think the best >> fix for IB is to generate an error message and not execute the SQL. >> There are too many move valuable things that R&D can spend time on to >> invest their time in making IB support mixed mode joins. >> >> -- >> Bill Todd (TeamB) > >
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Tue, 10 Jun 2008 13:09
Date: Tue, 10 Jun 2008 13:09
29 lines
2369 bytes
2369 bytes
Please let me know what R&D decide. And remember, again, that the syntax is correct in SQL-92. Hi. Massimiliano Trezzi. "Massimiliano Trezzi" <support_leavethis_@intesanet.it> ha scritto nel messaggio news:484a54b2$1@newsgroups.borland.com... > Hi, > it's me again! > > tell this to your bosses: > > the problem we have, is that we made a lot of projects with Oracle > Hyperion business untelligence suite (the old BrioQuery), and we developed > them on Interbase 5.6; now we migrated a lot of our customers to Interbase > 2007 and we discovered that these projects don't work because Hyperion > generate the queries with implicit joins for inner join and explicit joins > for outer ones. > I don't think I'm the only one with this problem and I don't think you > like have this defect and remember that this syntax is valid in SQL-92. > Maybe Oracle could change something in its product, but their database > works fine in this context and I think they don't mind of Interbase, > because, I repeat, this syntax is standard in SQL-92. > > Hi, > Massimiliano. >
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Tue, 10 Jun 2008 13:58
Date: Tue, 10 Jun 2008 13:58
8 lines
1541 bytes
1541 bytes
Note that TeamB members are not Borland employees. I am expressing my own opinion. If you think the behavior you have observed should be fixed enter a report with a reproducible test case in QC so the appropriate people at CodeGear can review it and decide what to do about it. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Tue, 10 Jun 2008 14:34
Date: Tue, 10 Jun 2008 14:34
19 lines
1992 bytes
1992 bytes
I'm sorry, I thought you were Borland employees. I entered the report, but how will I know if this issue will be fixed? I don't want to add comments and comments to the report, but I'd like to have some feedback. I'm a developer and my customers knows about their issue! Thank you, Massimiliano. "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio news:484e887e@newsgroups.borland.com... > Note that TeamB members are not Borland employees. I am expressing my > own opinion. If you think the behavior you have observed should be > fixed enter a report with a reproducible test case in QC so the > appropriate people at CodeGear can review it and decide what to do > about it. > > -- > Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Tue, 10 Jun 2008 16:39
Date: Tue, 10 Jun 2008 16:39
21 lines
2240 bytes
2240 bytes
Massimiliano Trezzi wrote: > I'm sorry, I thought you were Borland employees. No. These are peer support newsgroups. Occaisionally a CodeGear employee will post here, as Quinn Wildman did in response to your question, but that is unusual. The TeamB members are all volunteers. > I entered the report, but how will I know if this issue will be fixed? > I don't want to add comments and comments to the report, but I'd like > to have some feedback. I'm a developer and my customers knows about > their issue! You will not get any feedback. Either CodeGear will decide to fix the problem or they will not. Based on Quinn's post it seems likely that that if they do anything they will change IB to issue an error message and not execute the statement that contains bot implicit and explicit joins. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Thu, 12 Jun 2008 06:43
Date: Thu, 12 Jun 2008 06:43
140 lines
5596 bytes
5596 bytes
I see you are the only Codegear employee, so I quote here some of my
comments from other messages of the thread.
I never wrote manually a query like this, but some _good_ tools do it!
I think this is a bug beacuse:
SQL-92 should accept this syntax: it's bad but it's correct!
all other good databases work with this syntax,
you can have the same problem making a good query with implicit joins
made over some view with explicit outer joins (have I to look inside the
view before building the query?)
In Interbase 5.6 this worked
This is not as designed because:
it happens when fetching records not after parsing the query,
the error is not systematic, but it comes only with outer joins and only
in some circustances
the message is clearly related to some internal code (from sql we do not
manage fetching)
If it was designed as this, I'd expect a message like this "You cannot mix
explicit joins with implicit joins" and it should be systematic.
The problem we have, is that we made a lot of projects with Oracle Hyperion
business untelligence suite (the old BrioQuery), and we developed them on
Interbase 5.6; now we migrated a lot of our customers to Interbase 2007 and
we discovered that these projects don't work because Hyperion generate the
queries with implicit joins for inner join and explicit joins for outer
ones.
I don't think I'm the only one with this problem and I don't think you like
have this defect and remember that this syntax is valid in SQL-92.
Maybe Oracle could change something in its product, but their database works
fine in this context and I think they don't mind of Interbase, because, I
repeat, this syntax is standard in SQL-92.
Hi,
Massimiliano.
"Quinn Wildman (CodeGear Developer Support)" <qwildman@nospam.codegear.com>
ha scritto nel messaggio news:483d8dff$1@newsgroups.borland.com...
> R&D has determined SQL with implicit and explicit joins is bad SQL and
> therefore is not supported.
>
> Massimiliano Trezzi wrote:
>> Hi,
>>
>> I have a problem with Interbase 2007.
>>
>> If I make a query with some explicit left outer join (all in from clause)
>> and some implicit inner join (tables in from clause, conditions in where
>> clause) I have some chance to get an error: no current record for fetch
>> operation.
>>
>> The problem can arise using a view with left outer join in a query with
>> only implicit joins too.
>>
>> I agree that is not the best way to make a query, but some tools do so
>> and this make this trouble a big trouble!
>>
>> Here are the steps to reproduce the problem:
>>
>> CREATE TABLE A (
>> ID INTEGER NOT NULL PRIMARY KEY,
>> DES VARCHAR(128)
>> );
>>
>> COMMIT;
>>
>> CREATE TABLE B (
>> ID INTEGER NOT NULL PRIMARY KEY,
>> A_ID INTEGER,
>> DES VARCHAR(128)
>> );
>>
>> COMMIT;
>>
>> ALTER TABLE B ADD CONSTRAINT FK_B_A FOREIGN KEY (A_ID) REFERENCES A(ID);
>>
>> COMMIT;
>>
>> CREATE TABLE C (
>> ID INTEGER NOT NULL PRIMARY KEY,
>> B_ID INTEGER,
>> DES VARCHAR(128)
>> );
>>
>> COMMIT;
>>
>> ALTER TABLE C ADD CONSTRAINT FK_C_B FOREIGN KEY (B_ID) REFERENCES B(ID);
>>
>> COMMIT;
>>
>> COMMIT;
>>
>> INSERT INTO A (ID, DES) VALUES (1,'A-ONE');
>> INSERT INTO A (ID, DES) VALUES (2,'A-TWO');
>> INSERT INTO A (ID, DES) VALUES (3,'A-THREE');
>> INSERT INTO A (ID, DES) VALUES (4,'A-FOUR');
>> INSERT INTO A (ID, DES) VALUES (5,'A-FIVE');
>>
>> INSERT INTO B (ID, DES, A_ID) VALUES (1,'B-ONE',1);
>> INSERT INTO B (ID, DES, A_ID) VALUES (2,'B-TWO',2);
>> INSERT INTO B (ID, DES, A_ID) VALUES (3,'B-THREE',3);
>> INSERT INTO B (ID, DES, A_ID) VALUES (4,'B-FOUR',NULL);
>>
>> INSERT INTO C (ID, DES, B_ID) VALUES (1,'C-ONE',1);
>> INSERT INTO C (ID, DES, B_ID) VALUES (2,'C-TWO',2);
>> INSERT INTO C (ID, DES, B_ID) VALUES (3,'C-THREE',3);
>> INSERT INTO C (ID, DES, B_ID) VALUES (4,'C-FOUR',4);
>>
>> COMMIT;
>>
>>
>> /******************* TEST QUERIES *******************/
>>
>> /* OK! */
>> SELECT * FROM C INNER JOIN AB ON C.B_ID = AB.B_ID;
>>
>> /* NO CURRENT RECORD FOR FETCH OPERATION */
>> SELECT * FROM A, C LEFT OUTER JOIN B ON B.A_ID = A.ID WHERE C.B_ID = B.ID
>>
>> /* OK */
>> SELECT * FROM A LEFT OUTER JOIN B ON B.A_ID = A.ID, C WHERE C.B_ID = B.ID
>>
>> Thank you in advance.
>> Massimiliano Trezzi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Wed, 18 Jun 2008 13:06
Date: Wed, 18 Jun 2008 13:06
158 lines
5951 bytes
5951 bytes
Why don't you reply? Hi, Massimiliano Trezzi "Massimiliano Trezzi" <support_leavethis_@intesanet.it> ha scritto nel messaggio news:4850c5a0@newsgroups.borland.com... >I see you are the only Codegear employee, so I quote here some of my >comments from other messages of the thread. > > I never wrote manually a query like this, but some _good_ tools do it! > > I think this is a bug beacuse: > SQL-92 should accept this syntax: it's bad but it's correct! > all other good databases work with this syntax, > you can have the same problem making a good query with implicit joins > made over some view with explicit outer joins (have I to look inside the > view before building the query?) > In Interbase 5.6 this worked > > This is not as designed because: > it happens when fetching records not after parsing the query, > the error is not systematic, but it comes only with outer joins and > only > in some circustances > the message is clearly related to some internal code (from sql we do > not > manage fetching) > > If it was designed as this, I'd expect a message like this "You cannot > mix > explicit joins with implicit joins" and it should be systematic. > > The problem we have, is that we made a lot of projects with Oracle > Hyperion > business untelligence suite (the old BrioQuery), and we developed them on > Interbase 5.6; now we migrated a lot of our customers to Interbase 2007 > and > we discovered that these projects don't work because Hyperion generate the > queries with implicit joins for inner join and explicit joins for outer > ones. > I don't think I'm the only one with this problem and I don't think you > like > have this defect and remember that this syntax is valid in SQL-92. > Maybe Oracle could change something in its product, but their database > works > fine in this context and I think they don't mind of Interbase, because, I > repeat, this syntax is standard in SQL-92. > > Hi, > Massimiliano. > > > "Quinn Wildman (CodeGear Developer Support)" > <qwildman@nospam.codegear.com> ha scritto nel messaggio > news:483d8dff$1@newsgroups.borland.com... >> R&D has determined SQL with implicit and explicit joins is bad SQL and >> therefore is not supported. >> >> Massimiliano Trezzi wrote: >>> Hi, >>> >>> I have a problem with Interbase 2007. >>> >>> If I make a query with some explicit left outer join (all in from >>> clause) and some implicit inner join (tables in from clause, conditions >>> in where clause) I have some chance to get an error: no current record >>> for fetch operation. >>> >>> The problem can arise using a view with left outer join in a query with >>> only implicit joins too. >>> >>> I agree that is not the best way to make a query, but some tools do so >>> and this make this trouble a big trouble! >>> >>> Here are the steps to reproduce the problem: >>> >>> CREATE TABLE A ( >>> ID INTEGER NOT NULL PRIMARY KEY, >>> DES VARCHAR(128) >>> ); >>> >>> COMMIT; >>> >>> CREATE TABLE B ( >>> ID INTEGER NOT NULL PRIMARY KEY, >>> A_ID INTEGER, >>> DES VARCHAR(128) >>> ); >>> >>> COMMIT; >>> >>> ALTER TABLE B ADD CONSTRAINT FK_B_A FOREIGN KEY (A_ID) REFERENCES A(ID); >>> >>> COMMIT; >>> >>> CREATE TABLE C ( >>> ID INTEGER NOT NULL PRIMARY KEY, >>> B_ID INTEGER, >>> DES VARCHAR(128) >>> ); >>> >>> COMMIT; >>> >>> ALTER TABLE C ADD CONSTRAINT FK_C_B FOREIGN KEY (B_ID) REFERENCES B(ID); >>> >>> COMMIT; >>> >>> COMMIT; >>> >>> INSERT INTO A (ID, DES) VALUES (1,'A-ONE'); >>> INSERT INTO A (ID, DES) VALUES (2,'A-TWO'); >>> INSERT INTO A (ID, DES) VALUES (3,'A-THREE'); >>> INSERT INTO A (ID, DES) VALUES (4,'A-FOUR'); >>> INSERT INTO A (ID, DES) VALUES (5,'A-FIVE'); >>> >>> INSERT INTO B (ID, DES, A_ID) VALUES (1,'B-ONE',1); >>> INSERT INTO B (ID, DES, A_ID) VALUES (2,'B-TWO',2); >>> INSERT INTO B (ID, DES, A_ID) VALUES (3,'B-THREE',3); >>> INSERT INTO B (ID, DES, A_ID) VALUES (4,'B-FOUR',NULL); >>> >>> INSERT INTO C (ID, DES, B_ID) VALUES (1,'C-ONE',1); >>> INSERT INTO C (ID, DES, B_ID) VALUES (2,'C-TWO',2); >>> INSERT INTO C (ID, DES, B_ID) VALUES (3,'C-THREE',3); >>> INSERT INTO C (ID, DES, B_ID) VALUES (4,'C-FOUR',4); >>> >>> COMMIT; >>> >>> >>> /******************* TEST QUERIES *******************/ >>> >>> /* OK! */ >>> SELECT * FROM C INNER JOIN AB ON C.B_ID = AB.B_ID; >>> >>> /* NO CURRENT RECORD FOR FETCH OPERATION */ >>> SELECT * FROM A, C LEFT OUTER JOIN B ON B.A_ID = A.ID WHERE C.B_ID = >>> B.ID >>> >>> /* OK */ >>> SELECT * FROM A LEFT OUTER JOIN B ON B.A_ID = A.ID, C WHERE C.B_ID = >>> B.ID >>> >>> Thank you in advance. >>> Massimiliano Trezzi >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Bill Todd [TeamB]
Date: Wed, 18 Jun 2008 14:14
Date: Wed, 18 Jun 2008 14:14
12 lines
1814 bytes
1814 bytes
These are peer support newsgroups. Neither Quinn nor any other CodeGear employee is under any obligation to reply to your posts. In fact, no one is under any obligation to reply to your posts. Your last message does not contain anything that you have not said before and Quinn made CodeGear's position very clear. The fact that you continue to post the same arguments that you have already made indicates to me that you are just looking for someone to argue with and the people who volunteer their time to try to help others on these newsgroups have better things to do with their time than engage in a pointless argument. -- Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Massimiliano Trezzi
Date: Wed, 18 Jun 2008 15:28
Date: Wed, 18 Jun 2008 15:28
28 lines
2509 bytes
2509 bytes
I'm simply trying to understand what CodeGear is going to do with this problem. I tried to demonstrate that this is a bug and they should fix it (Remembere that Interbase should be compatible with SQL ANSI 92!), but now I see that they don't mind about their customer's problems. I didn't receive any official reply! I'm a developer and when a customer of mine has a problem I'm here with my face to understand and fix if I should, CodeGear can ignore its customers! I see in THEIR newsgroups and in their products that in the last few years are always worst. Massimiliano Trezzi. "Bill Todd [TeamB]" <no@no.com> ha scritto nel messaggio news:48591830$1@newsgroups.borland.com... > These are peer support newsgroups. Neither Quinn nor any other CodeGear > employee is under any obligation to reply to your posts. In fact, no > one is under any obligation to reply to your posts. Your last message > does not contain anything that you have not said before and Quinn made > CodeGear's position very clear. The fact that you continue to post the > same arguments that you have already made indicates to me that you are > just looking for someone to argue with and the people who volunteer > their time to try to help others on these newsgroups have better things > to do with their time than engage in a pointless argument. > > -- > Bill Todd (TeamB)
Re: no current record for fetch operation mining explicit left joins and implicit inner joins
Author: Wayne Niddery (TeamB)
Date: Wed, 18 Jun 2008 17:59
Date: Wed, 18 Jun 2008 17:59
19 lines
2155 bytes
2155 bytes
"Massimiliano Trezzi" <support_leavethis_@intesanet.it> wrote in message news:4859298c@newsgroups.borland.com... > I didn't receive any official reply! If you want an *official* reply then you must raise an official support case with CodeGear. As you've already been told, these are *peer* supported newsgroups, they are not CodeGear support. CodeGear participation here is voluntary and non-official. For whatever it's worth to you, I agree that it should either work or raise an error rather than simply giving wrong results, but there will be no official resolution here in these groups. Raise a support case. -- Wayne Niddery - TeamB (www.teamb.com) Winwright, Inc. (www.winwright.ca)
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads