?
Solved

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

Posted on 2003-03-28
5
Medium Priority
?
611 Views
Last Modified: 2013-12-09
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
Comment
Question by:eruj
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
5 Comments
 
LVL 2

Assisted Solution

by:Stummel
Stummel earned 200 total points
ID: 8234406
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
 
LVL 9

Accepted Solution

by:
tkalchev earned 600 total points
ID: 8239566
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
 
LVL 10

Expert Comment

by:kacor
ID: 8325139
Hi eruj,
if the offered solutions helped you please accept one of them to honour the experts who helped you

Janos
0
 
LVL 1

Expert Comment

by:asmodraxas
ID: 8808268
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

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

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…
Backups and Disaster RecoveryIn this post, we’ll look at strategies for backups and disaster recovery.
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…

801 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question