• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 621
  • Last Modified:

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

Hi,

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.

Is it maybe another way to do that?

Thanx
0
eruj
Asked:
eruj
2 Solutions
 
StummelCommented:
Hi Eruj,

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
...

CU Stummel
0
 
tkalchevCommented:
Just a suggestion :

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

declare variable new_sql varchar(500);
declare variable new_sql_blob blob;

declare variable p1 integer; /*your parameters*/
...

begin
 
  new_sql = "select * from t1,t2, ... where ";

  /* 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 :

CREATE TABLE RDB$PROCEDURES (
    RDB$PROCEDURE_NAME CHAR (31) character set UNICODE_FSS,
    RDB$PROCEDURE_ID SMALLINT,
    RDB$PROCEDURE_INPUTS SMALLINT,
    RDB$PROCEDURE_OUTPUTS SMALLINT,
    RDB$DESCRIPTION BLOB sub_type 1 segment size 80,
    RDB$PROCEDURE_SOURCE BLOB sub_type 1 segment size 80,
    RDB$PROCEDURE_BLR BLOB sub_type 2 segment size 80,
    RDB$SECURITY_CLASS CHAR (31) character set UNICODE_FSS,
    RDB$OWNER_NAME CHAR (31) character set UNICODE_FSS,
    RDB$RUNTIME BLOB sub_type 5 segment size 80,
    RDB$SYSTEM_FLAG SMALLINT);

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';

  for
    select v1,v2,...,v10 from
    PRC1 into :v1,:v2,...,v10
  do
    suspend;


end


This can help you I believe

 
0
 
kacorretiredCommented:
Hi eruj,
if the offered solutions helped you please accept one of them to honour the experts who helped you

Janos
0
 
asmodraxasCommented:
The way that I have handled situations like this is:

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.

Hope it helps.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now