Queries that have parameters that are set by the datasource are failing with an access violation when opened.

For example,
SELECT ID, Name
  FROM CategoryItem
  WHERE CategoryListID = :ID

It works OK if the parameter is not set via the datasource.

This appears to be similar to the problem documented in the message **GUID as Parameter in TEDBQuery**.

Richard,

<< Queries that have parameters that are set by the datasource are failing
with an access violation when opened.

For example,
SELECT ID, Name
  FROM CategoryItem
  WHERE CategoryListID = :ID

It works OK if the parameter is not set via the datasource. >>

That shouldn't make any difference at all.  Are you sure that it runs okay
when just set as a normal parameter without the datasource set ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Richard,

<< Queries that have parameters that are set by the datasource are failing
with an access violation when opened. >>

I've tested both with normal parameters, and with a datasource set, and both
are working fine in the 1.01 version going out today.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Queries that have the parameters set via the datasource were failing with an Access Violation when the querie's ACTIVE property were set to TRUE in the Object Inspector.

This can be prevented by assigning the parameter a TYPE other than UNASSIGNED and a VALUE in the Object Inspector then the ACTIVE property can be set to TRUE.

This is only required when the DATASOURCE is defined and it was not required for DBISAM applications.




"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Richard,

<< Queries that have parameters that are set by the datasource are failing
with an access violation when opened. >>

I've tested both with normal parameters, and with a datasource set, and both
are working fine in the 1.01 version going out today.

--
Tim Young
Elevate Software
www.elevatesoft.com

Richard,

<< Queries that have the parameters set via the datasource were failing with
an Access Violation when the querie's ACTIVE property were set to TRUE in
the Object Inspector.

This can be prevented by assigning the parameter a TYPE other than
UNASSIGNED and a VALUE in the Object Inspector then the ACTIVE property can
be set to TRUE.

This is only required when the DATASOURCE is defined and it was not required
for DBISAM applications. >>

Could you send me a project that demonstrates what you're saying ?  Also,
did you verify that you're using the latest 1.01 run-time and design-time
BPLs and not earlier versions ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Attached is a small Delphi 5 project with the SQL to create the DB. I am using EDB V 1.01.

Thank you for the fix for the problem with NULL columns causing the Check constraints to fail.


Richard Harding
Windella Computer Knowhow
28 Freeman Drive
Lochinvar NSW 2321
Phone:   61 2 4930 7336
Mobile:   0419 016 032
email:   rharding@wck.com.au

Richard,

<< Attached is a small Delphi 5 project with the SQL to create the DB. I am
using EDB V 1.01. >>

Okay, it's a two-fold issue.  The main issue is that the creation order of
the components is such that the TEDBQuery is trying to reference columns in
the driver data source before that data source is opened.  However, EDB
should just quietly ignore this, and it isn't, so that is the bug.  A fix
will be in 1.01 build 2, however the workaround is to change the creation
order in the data module so that the TEDBQuery is created last after the
TEDBTable components.

<< Thank you for the fix for the problem with NULL columns causing the Check
constraints to fail.  >>

No problem.  It's no good if you can't move your data over.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Richard,

<< Attached is a small Delphi 5 project with the SQL to create the DB. I am
using EDB V 1.01. >>

Okay, it's a two-fold issue.  The main issue is that the creation order of
the components is such that the TEDBQuery is trying to reference columns in
the driver data source before that data source is opened.  However, EDB
should just quietly ignore this, and it isn't, so that is the bug.  A fix
will be in 1.01 build 2, however the workaround is to change the creation
order in the data module so that the TEDBQuery is created last after the
TEDBTable components.

*** Thank You . . .  I appreciate the great service and effort that goes into creating EDB.

Richard Harding
Windella Computer Knowhow
28 Freeman Drive
Lochinvar NSW 2321
Phone:   61 2 4930 7336
Mobile:   0419 016 032
email:   rharding@wck.com.au