Tim

You know you said that Filters and WHERE clauses where the same (apart from JOINS) well I've just found you can't add a table qualifier. I know it would be silly to do so but it is an important difference.

Roy Lambert

and as a ps

How about user defined functions?

Roy Lambert

Roy,

<< How about user defined functions? >>

Actually, we're allowing them but we shouldn't be, so the answer is no (at
least as of 1.03).

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< You know you said that Filters and WHERE clauses where the same (apart
from JOINS) well I've just found you can't add a table qualifier. I know it
would be silly to do so but it is an important difference. >>

I've noted this in the manual already for 1.03:

http://www.elevatesoft.com/edb1d7_setting_filters_tables_query.htm

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< How about user defined functions? >>
>
>Actually, we're allowing them but we shouldn't be, so the answer is no (at
>least as of 1.03).

Why shouldn't you allow them. I already use them in DBISAM and it would be nice to do so in ElevateDB.

Roy Lambert

Tim



>I've noted this in the manual already for 1.03:
>
>http://www.elevatesoft.com/edb1d7_setting_filters_tables_query.htm

Understand most of that apart from "Query expressions"

Roy Lambert

Roy,

<< Understand most of that apart from "Query expressions" >>

Query expressions are expressions that are queries.  That is, they are
sub-queries, effectively, such as the case with IN or EXISTS.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Why shouldn't you allow them. I already use them in DBISAM and it would
be nice to do so in ElevateDB. >>

They're not bound the same way as in DBISAM.  In DBISAM they are coded in
Delphi as part of the engine so there are no contextual issues to deal
with - they behave just like any other native system function in DBISAM.
This is not the case with EDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Query expressions are expressions that are queries. That is, they are
>sub-queries, effectively, such as the case with IN or EXISTS.

Ahh - its like learning a new language

Roy Lambert

Tim

><< Why shouldn't you allow them. I already use them in DBISAM and it would
>be nice to do so in ElevateDB. >>
>
>They're not bound the same way as in DBISAM. In DBISAM they are coded in
>Delphi as part of the engine so there are no contextual issues to deal
>with - they behave just like any other native system function in DBISAM.
>This is not the case with EDB.

I'm beginning to dislike ElevateDB again. This is the second very useful item that's disappeared. Are there any more nasty surprises? Losing the ability to do text searches on unindexed fields was bad enough - I can write my own routine BUT now I find I can't use it in a filter. That seriously screws one major app and two minor ones in terms of conversion.

Roy Lambert