How not to consider all of the parameters in the WHERE clause of an IB procedure

how can i arrange a WHERE clause in a database select procedure in Interbase, if not all of the values of the input parameters should always be considered ?

Example: i have 3 input parameters: year, account_no and color. Sometimes i want to return only the records which match the given color (the other two parameters aren't important) - so the WHERE part of the sql statement would look like "WHERE table.color = :color"; on the other hand, sometimes i need also to consider the value of the year parameter -> the where part is: "WHERE table.color = :color AND table.year = :year". As you can see i should be able to consider any possible combination of the parameters.

In Delphi i can easily do that, because i build an sql statement dynamically (in a string) and then assign it to a IBQuery. Is it possible to do the same (or similar) thing also in IB ( to dynamically change the content of a WHERE clause ), or is the database procedure somehow "hardcoded" and you can't assign a string to the WHERE clause (the string could also be an input parameter)?

The result i want to achieve is to have only one procedure (or better, only one select clause) for all possible combinations of the input parameters. The example presented here has 3 parameters, but in my application i have 10 of them, so it would be practically impossible to write an select clause for every possible combination of the parameters.

this is not possible in current Interbase implementations. In Stored procedures _all_ parameters must be specified. Its not possible to build an sql statement - this is a requested feature for firebird 2.

One thing that worked for me is, that if a value for a parameter is 0, i do another query.

Pseudocode:

if (param1 = 0 and param2 = 0)
for select * from colors
...
end
if param1 = 0 and param2 != 0)
for select * from colors where color =:param2
...
end
...

You can try to modify the source of a stored procedure "on the fly". You can create one SP, which returns all the fields which you need in your query and leave the body blank, e.g.

create procedure PRC1
returns
(v1 integer, v2 date, ... )
as
begin

end

Then you can put the actual values of the parameters into a table for example and create a second SP, which can produce the required SQL, depending of the values of the parameters. For example s.th like

create procedure PRC2
returns
(v1 integer, v2 date, .... ) /* the same things as in the first SP */
as

/* read from the table what values are present */
select p1 from parameters_table into :p1;
if (not(p1 is null)) then
new_sql = new_sql || " (p1=" || p1 || ") and ";
/* and so on for all parameters. Remove the last AND in the end */

new_sql = "begin " || new_sql || " end";

Now you can update the body of SP 1 ( PRC1 ). Interbase saves all the procedure bodies into a system table, called RDB$PROCEDURES. Actually the structure of this system table is :

RDB$PROCEDURE_NAME id the name of the procedure, RDB$PROCEDURE_SOURCE id the body.

As you can see the body is of type blob. There are some UDFs, which can convert BLOB to varchar and vice versa. I cannot remember in this moment what was the correct syntax of the functions, but you can easily find it over internet, i am sure. So let's say we have a function str2blob, which has input parameter varchar and returns blob.

So, let's continue with the body f PRC2 :

new_sql_blob = str2blob(mew_sql);

update rdb$procedures set rdb$procedure_source=:new_sql_blob where rdb$procedure_name='PRC1';

SELECT * FROM TABLE_FOO
WHERE (:year IS NULL OR year=:year)
AND (:account_no IS NULL OR account_no=:account_no)
AND (:color IS NULL OR color=:color);

and so on and so forth. If any single parameter is set to NULL it is basically ignored in the select statement. You are still required to have all the parameters as input to the procedure but you can now have control over which of them matter.

Recently, Microsoft released a best-practice guide for securing Active Directory. It's a whopping 300+ pages long. Those of us tasked with securing our company’s databases and systems would, ideally, have time to devote to learning the ins and outs…

Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB.
To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…