Hi all,

Thank you for all your answers.

However, it does not realy help me. If I would start a new project
from scratch, I would probably use temporary tables, views, etc so
that I would not have to use an IN caluse. However, I currently have
to work with existing software and logic.

In fact, for the moment, when the user select customers, this is
according to several criterias that are computed directly into the
computer memory. So, each criteria are not obligatory a field of the
CUSTOMERS table. This is why it is more complicated.

So, if each time a user select customers to include in a report, I
have to create a temporary table and add thousands of customer codes
to that table so that the report can run fine, I think it could be a
lot of touble. Also, note that I'm not sure yet if I would be able to
correctly link this with the report generator that is a separate
program. Also, note that the same user can run several reports with
dirrefent criterias at the same time. So, it is again more
complicated.

So, this is why I asked my original question about the limitation of
the IN clause. Note here that I understand that having an SQL query
with thousands of items in the IN clause is not the correct way to
proceed. Unfortunately, it looks like this is the only way I have for
the moment according to the current situation.

So, why this is so terrible to remove the 1499 items limitation into
Firebird?
And at the same time, again, since computers are now very fast and
these same computers now have GigaBites of RAM, why not remove or
increase the 64K limit of the statement size?

Is it so terrible asking for such improvement?
Is it so dangerous?

Thanks again for the time you are taking to answer my post.

G. Plante