Please Help: BDE16 GPF 
Author Message
 Please Help: BDE16 GPF

Hi,
using SQL-statements like this causes a GPF in the BDE 16 Bit (IDQRY01.DLL).
Inprise Helpline told me that they do have heard about that but theres no
fix. I would like t know the exact reason to avoid GPFs in my application.
Example tested with DBF and Paradox files and all BDE 2.5x Versions uses
TQUERY component:

select * from kd, ld, pat where
(pat.ptnum=ld.ptnum) and
 (pat.ptnum=kd.ptnum) and
 ((:today - pat.gebdat) < 30000)

Removing the parameter :today and using a fixed number does not solve the
problem. Most likely it seems to be a problem using calculation and
comparison in one statement?

Any help or idea is very, very welcome!

Michael Schumann



Fri, 27 Apr 2001 03:00:00 GMT  
 Please Help: BDE16 GPF


Quote:
>using SQL-statements like this causes a GPF in the BDE 16 Bit (IDQRY01.DLL).
>Inprise Helpline told me that they do have heard about that but theres no
>fix. I would like t know the exact reason to avoid GPFs in my application.
>Example tested with DBF and Paradox files and all BDE 2.5x Versions uses
>TQUERY component:

>select * from kd, ld, pat where
>(pat.ptnum=ld.ptnum) and
> (pat.ptnum=kd.ptnum) and
> ((:today - pat.gebdat) < 30000)

>Removing the parameter :today and using a fixed number does not solve the
>problem. Most likely it seems to be a problem using calculation and
>comparison in one statement?

The SQL in 16-bit BDE had its quirks. SQL was handled by the QBE engine,
and so the translation from SQL to QBE did not always adequately handle
complex comparisons. Of the problems people have reported with 16-bit BDE's
SQL implementation, I think most had to do with complex conditions in WHERE
clauses. The 32-bit BDE introduced a true SQL engine, separating this
functionality from the QBE engine. It is considerably more robust.

I do not have any specific solutions for you. I do have a couple
suggestions, things to try. One is to test the same SQL statement with only
one condition in the WHERE clause -- the one with the calculation. As the
other two conditions are there to enable the multi-table join, it would
also involve removing the other tables from the statement.

  SELECT *
  FROM pat
  WHERE ((:today - pat.gebdat) < 30000)

Does this variation on your original statement work or produce the same
error?

As the majority of past problems were to do with complex conditions in a
WHERE clause, you might try separating the join conditions out of the WHERE
clause. Use explicit INNER JOIN syntax to do this, with the join conditions
in ON clauses. This serves to simplify the WHERE clause.

  SELECT *
  FROM pat
    INNER JOIN kd
      ON (pat.ptnum = kd.ptnum)
    INNER JOIN ld
      ON (pat.ptnum = ld.ptnum)
  WHERE ((:today - pat.gebdat) < 30000)

What data type are this Today parameter and the Pat.GebDat column? Does
using the CAST function to force them both to a specific data type
alleviate the problem?

  SELECT *
  FROM pat
    INNER JOIN kd
      ON (pat.ptnum = kd.ptnum)
    INNER JOIN ld
      ON (pat.ptnum = ld.ptnum)
  WHERE ((CAST(:today AS INTEGER) - CAST(pat.gebdat AS INTEGER)) < 30000)

Or are these two tokens of the DATE or TIMESTAMP data type?

//////////////////////////////////////////////////////////////////////////
Steve Koterski                      "The knowledge of the world is only to
Technical Publications              be acquired in the world, and not in a
INPRISE Corporation                 closet."
http://www.inprise.com/delphi          -- Earl of Chesterfield (1694-1773)



Sat, 28 Apr 2001 03:00:00 GMT  
 Please Help: BDE16 GPF
Steve covered things pretty well.  Since the 16-bit BDE always
converts SQL to an equivalent QBE statement before executing it,
my strategy would be to:
(1) Experiment interatively with either Paradox or Database Desktop
to find a QBE query that works, then use the menu choice "Query -
Show SQL" to convert it to SQL.  If you don't like the SQL statement
that's autogenerated, modify it one step at a time in Paradox or
Database Desktop, checking at each point to make sure your modifications
will still execute.
(2) If you can't do it all in one query, do it in two or three.
If the net result of the first query is to limit the number of
records to be processed, that sequence of queries may actually
execute faster than your single query.


: >using SQL-statements like this causes a GPF in the BDE 16 Bit (IDQRY01.DLL).
: >Inprise Helpline told me that they do have heard about that but theres no
: >fix. I would like t know the exact reason to avoid GPFs in my application.
: >Example tested with DBF and Paradox files and all BDE 2.5x Versions uses
: >TQUERY component:
: >
: >select * from kd, ld, pat where
: >(pat.ptnum=ld.ptnum) and
: > (pat.ptnum=kd.ptnum) and
: > ((:today - pat.gebdat) < 30000)
: >
: >Removing the parameter :today and using a fixed number does not solve the
: >problem. Most likely it seems to be a problem using calculation and
: >comparison in one statement?

: The SQL in 16-bit BDE had its quirks. SQL was handled by the QBE engine,
: and so the translation from SQL to QBE did not always adequately handle
: complex comparisons. Of the problems people have reported with 16-bit BDE's
: SQL implementation, I think most had to do with complex conditions in WHERE
: clauses. The 32-bit BDE introduced a true SQL engine, separating this
: functionality from the QBE engine. It is considerably more robust.

: I do not have any specific solutions for you. I do have a couple
: suggestions, things to try. One is to test the same SQL statement with only
: one condition in the WHERE clause -- the one with the calculation. As the
: other two conditions are there to enable the multi-table join, it would
: also involve removing the other tables from the statement.

:   SELECT *
:   FROM pat
:   WHERE ((:today - pat.gebdat) < 30000)

: Does this variation on your original statement work or produce the same
: error?

: As the majority of past problems were to do with complex conditions in a
: WHERE clause, you might try separating the join conditions out of the WHERE
: clause. Use explicit INNER JOIN syntax to do this, with the join conditions
: in ON clauses. This serves to simplify the WHERE clause.

:   SELECT *
:   FROM pat
:     INNER JOIN kd
:       ON (pat.ptnum = kd.ptnum)
:     INNER JOIN ld
:       ON (pat.ptnum = ld.ptnum)
:   WHERE ((:today - pat.gebdat) < 30000)

: What data type are this Today parameter and the Pat.GebDat column? Does
: using the CAST function to force them both to a specific data type
: alleviate the problem?

:   SELECT *
:   FROM pat
:     INNER JOIN kd
:       ON (pat.ptnum = kd.ptnum)
:     INNER JOIN ld
:       ON (pat.ptnum = ld.ptnum)
:   WHERE ((CAST(:today AS INTEGER) - CAST(pat.gebdat AS INTEGER)) < 30000)

: Or are these two tokens of the DATE or TIMESTAMP data type?

: //////////////////////////////////////////////////////////////////////////
: Steve Koterski                      "The knowledge of the world is only to
: Technical Publications              be acquired in the world, and not in a
: INPRISE Corporation                 closet."
: http://www.inprise.com/delphi          -- Earl of Chesterfield (1694-1773)

--
============================================================

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



Thu, 03 May 2001 03:00:00 GMT  
 Please Help: BDE16 GPF
I just want to say thanks to Steve and Richard for their help with the 16BIT
BDE GPF problem.  I'm still fiddling around and will post any interesting
additional info.

Michael Schumann



Tue, 08 May 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. BDEcfg32 gives GPF...please help !

2. GPF's in COMPLIB.DCL!!! please help

3. GPF's in COMPLIB.DCL!!! please help

4. HELP!!!! network - paradox - bde16

5. BDE16-OS2-Paradox-HELP!!!!!!

6. Help with a GPF

7. HELP: GPF with more than 85000 records!!!!

8. Help for GDI GPF on using bitmap

9. HELP: GPF after an SQL query in Delphi1

10. Edit causing GPF-Help!

11. gpf / MDI Application HELP!

12. help : GPF in idapi01.dll

 

 
Powered by phpBB® Forum Software