Home/ Questions/Q 3939974
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T00:21:46+00:00

Ok, So i know this questions has been asked. and everything i read has

  • 0

Ok, So i know this questions has been asked. and everything i read has been “well.. you can do it using dynamic DSL, but dont do it” my question is why. I’m still new at this so I’m learning so bear with me but here is what i’m doing.
I want to use a stored procedure to create a dynamic view (but not a temporary table) the view has two dates that it uses to establish a beginning and ending date. it looks something like this:

create or replace view MyView as
SELECT
   A.COLUMN_A
   FUNCTION1(to_date('2/10/2011','MM/DD/YYYY') TOTAL1,
   FUNCTION2(to_date('2/15/2011','MM/DD/YYYY') TOTAL2
FROM TABLE_A A;

This view is then used to generate the data needed for a report in crystal.
The problem is that we are about to start using these same sql statements in another language. (we are currently using delphi but to about working on another language (but i dont know what the other language is)) the reason I want to create the view in a stored procedure is, because a) the view is dynamic, and based off the date range selected by the user and b) instead of having to put in some rather large views in multiple languages (that have to be created on the fly due to the changing date range selection) onlt the single line for the function and the parameters would need to be passed. Alot of what i read has said that using Dynamic SQL to create a view is bad, but knowing that its already a dynamic view created specifically for the user on the fly, does anyone see an issue with that? I’m asking because I dont want to get myself into something down the road that I wouldnt be able to get myself out of with out wanting to yank all my hair out.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Generating a view is only a good idea if it’s really code-generation and generally fairly permanent. Because it’s a schema change, it should be viewed as an advanced technique, and I always try to use database techniques in order of complexity.

    i.e. For certain table/view designs, if it can be done with a view, try that. If an indexed view is really needed for performance, try that. Alternatively, maybe a computed column or a persisted computed column. Perhaps an inline table-valued function, or a multi-statement table-valued function, or potentially a stored procedure. So I try to escalate only when necessary.

    In your case, that “view” can also be an inline table-valued function in SQL Server (and DB2 at least) and such a creature is just like a parametrized view. You can also use a parametrized stored procedure directly from most reporting tools (and of course from most language/db libraries).

    • 0