Example: Query tool C

Query tool C allows complex decision support-type queries to be made by defining complex query criteria with a point-and-click interface. You might end up with SQL that looks like this for a query:

   SELECT A.COL1, B.COL2, C.COL3 , etc...
      FROM A, B, C, etc...
         WHERE many complex inner and outer joins are specified

That you did not have to write this complex query is advantageous, but beware that your tool may not actually process this statement. For example, one tool might pass this statement directly to the ODBC driver, while another splits up the query into many individual queries, and processes the results at the client, like this:

   SQLExecDirect("SELECT * FROM A")
   SQLFetch() all rows from A
   SQLExecDirect("SELECT * FROM B")
   SQLFetch() all rows from B
 
   Process the first join at the client
 
   SQLExecDirect("SELECT * FROM C")
   SQLFetch() all rows from C
 
   Process the next join at the client
   .
   .
   .
   And so on...

This approach can lead to excessive amounts of data being passed to the client, which will adversely affect performance. In one real-world example, a programmer thought that a 10-way inner/outer join was being passed to ODBC, with four rows being returned. What actually was passed, however, was 10 simple SELECT statements and all the FETCHes associated with them. The net result of four rows was achieved only after 81,000 ODBC calls were made by the tool. The programmer initially thought that ODBC was responsible for the slow performance, until the ODBC trace was revealed.