>
> I think that's exactly what it will return. Let's replace the parameters with numbers:
>
> SELECT *
> FROM GLJOUR
> WHERE Company >= 10
> AND (Company > 10
> OR (Account >= 1000
> AND (Account > 1000
> OR (Division >= ...
>
> So, company < 10 will not be returned, > 10 will be returned regardless, whereas = 10 will be returned if the account field is > 1000. If account = 1000 it will depend on any possible criteria for division and so on.
>
>

I sat down and charted it out and I do believe you are right. My
apologies. A bit difficult to understand though (at least for me).

> Of course, you would have to add ORDER BY and preferrably reduce the result set a bit through using ROWS (or FIRST, but ROWS is standard and FIRST Firebird specific). I'm sure you could agree on some sensible number of rows with your employer, even people used to ISAM files know they rarely need millions of rows returned.
>
>

The trouble is you don't know, up front, how many rows the programmer
wants to return. If he / she is doing a month end aging you might very
well want millions of rows returned. Asking them to decide how many
rows they want at the time the request is made requires them to do a
fairly in depth analysis of what the program does when they are
converting it. When you have thousands of programs to do you want to
keep the amount of effort required to convert each one to a bare
minimum. Imposing an unconditional maximum on the number of rows
returned has the potential to cause some programs to fail, or even worse
to fail intermittently.

At some point we are going to have to come to some compromise between
ease of conversion and performance but we haven't reach that point yet.
It seems to make sense to make the conversion process as painless as
possible and then address the poorly performing programs as they reveal
themselves. At that point we can hand craft the SQL for those programs
to get performance to an acceptable level.

> I liked Philips idea of using a computed field, although whilst I think it would be the best solution for CHAR (and VARCHAR) fields (at least as long as they all use the same character set and collation), I fear it could be cumbersome when some fields are numbers.
>

Or dates, which is even more common. Although we can control that to
some extent by carefully choosing the appropriate data type when we
convert the data. We are talking Cobol here so they wouldn't be
surprised to see 000100 in a Varchar field rather than 100 in a numeric
field. Not a really clean approach though. And it would be nasty for
non-Cobol programs accessing the same data.

Lots to ponder.



[Non-text portions of this message have been removed]