This could be a bug in 1.05 bld2.  I have a very simple query that is written during the design-time.  This query has the following SELECT clause:

SELECT AccountNo,
           AccountName,
           AccountPhone

FROM TB_AccountsChart

WHERE  AccountType = 1
AND      BranchSysNo = :iBranchSysNo

During run-time the parameters are passed as following:

qryAccounts.Close;
qryAccounts.ParamByName('iBranchSysNo').Value := 1;
qryAccounts.Open;


This qury takes forever if the "RequestSensitive" property is not set to True.  Any idea?

NOTE: This table has around 1600 records and has indexes for "BranchSysNo" and "AccountType" fields.

Abdulaziz,

<< This qury takes forever if the "RequestSensitive" property is not set to
True.  Any idea? >>

Could you post the query execution plan ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

I have more news to you.  I rolled back to 1.04 build 6 and same problem occurs.  I cannot generate the execution plan because I got an error.  I
opened the query and waited for 45 minutes and then left out and came back after 2 hours and the application has an error.  The hard disk's light
was on all the time and CPU was burning.  But if I set the "RequestSensitive" property to "TRUE" then it executes the query in no-time.  This time I
am running the query against a table that has around 11K records.  Here is the execution plan:

================================================================================
SQL Query (Executed by ElevateDB 1.05 Build 2)

Note: The SQL  shown here is generated by ElevateDB and may not be exactly the
same as the SQL that was originally entered.  However, none of the differences
alter the execution results in any way.

================================================================================

SELECT ALL
"AccountNo" AS "AccountNo",
"AccountName" AS "AccountName",
"AccountPhone" AS "AccountPhone"
FROM "TB_AccountsChart"
WHERE "AccountType" = 1 AND "BranchSysNo" = ?

Source Tables
-------------

TB_AccountsChart: 10584 rows

Result Set
----------

The result set was sensitive
The result set consisted of zero or more rows
The result set was ordered using the table's natural order

Filtering
---------

The following filter condition was applied to the Query table:

"BranchSysNo" = ? [Index scan: 4311 keys, 69632 bytes estimated cost] AND
"AccountType" = 1 [Index scan: 7766 keys, 126976 bytes estimated cost]

================================================================================
3876 row(s) returned in 0.11 secs
================================================================================

Tim,

<<WHERE "AccountType" = 1 AND "BranchSysNo" = ?>>

Notes the value that is passed to the "BranchSysNo"!!!  It supposed to be "1".

Abdulaziz,

<< I have more news to you.  I rolled back to 1.04 build 6 and same problem
occurs.  I cannot generate the execution plan because I got an error.  I
opened the query and waited for 45 minutes and then left out and came back
after 2 hours and the application has an error.  The hard disk's light was
on all the time and CPU was burning.  But if I set the "RequestSensitive"
property to "TRUE" then it executes the query in no-time.  This time I am
running the query against a table that has around 11K records.  Here is the
execution plan: >>

Would it be possible for you to send me the table that you're using ?  I
suspect that the issue is related to what Dave Harrison just reported,
specifically that there's an issue with the refreshing of insensitive query
result sets during query execution.

--
Tim Young
Elevate Software
www.elevatesoft.com

Abdulaziz,

<< Notes the value that is passed to the "BranchSysNo"!!!  It supposed to be
"1". >>

Don't worry about that - EDB simply shows ? for any dynamic parameters.
However, I'll see about getting that changed to reflect the actual parameter
value used for the execution.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Would it be possible for you to send me the table that you're using ?>>


I have sent you the table.

Abdulaziz,

<< I have sent you the table. >>

Sorry, I should have mentioned that I need the .EDBCat catalog file also for
the database in which the table resides.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Sorry, I should have mentioned that I need the .EDBCat catalog file also for
the database in which the table resides.>>


Sent.

Abdulaziz,

<< Sent. >>

Okay, the issue is related to Dave Harrison's report about cancelling
insensitive queries - there's an issue with the refresh mechanism as it
relates to insensitive query result sets.   A fix will be in 1.06.

--
Tim Young
Elevate Software
www.elevatesoft.com