[sql] Variabelen declareren binnen een VIEW

[Chillz]

Ik wil een view maken,
hierin zou echter een variabele moeten komen.

Volgens mn collega gaat dit niet:"geen variabelen in een view"
maar ik kan me herinneren dat ik ooit heb gehoord dat het op de een of andere manier toch echt kan werken...

code:

CREATE  VIEW [dbo].[View_Data]
AS

DECLARE @jaartal decimal(4)
SET @jaartal = ((SELECT Algemene_parameters_Huidige_jaar FROM [dbo].[Algemene_parameters]))

SELECT........ AS........ FROM........

in de Select komt de variabele voor, tabelnamen met t huidige jaartal moeten getoond worden (zijn ook andere jaartallen aanwezig namelijk)

Had eerst vooraf gedeclareerd, maar dan krijg je de melding dat Create View de eerste statement moet zijn.
Heb ook geprobeerd een tijdelijke tabel aan te maken en met GO's de Create View toch als eerste te laten 'lijken' staan, maar dan nog staan er variabelen in je View en een declaratie in je script...

weet iemand of het überhaupt mogelijk is variabelen hier te gebruiken?
tips voor mijn script, de plaatsing van de Declare?

[Freee!!]

Standaard kan dit gewoon niet. Mogelijk dat er SQL-dialecten zijn die zoiets wel toestaan, maar ik ken ze niet. Mogelijk is het een idee om aan te geven welke SQL-engine/database je gebruikt.

[JohanDM]

Er vanuit gaande dat je met MS SQL Server werkt: probeer eens CREATE PROCEDURE ipv CREATE VIEW, dan maak je een stored procedure aan, die net als een view resultaten kan teruggeven

[JaQ]

je kan in een view geen variabelen zetten. De enige oplossing is een script gebruiken of een stored procedure.
Het lijkt me trouwens wel erg handig als je het rdbms er even bijzet..

[djluc]

Het lijkt me trouwens wel erg handig als je het rdbms er even bijzet..

Het kan natuurlijk ook zo zijn dat hij database onafhankelijk wil proggen, of in ieders geval volgens de SQL standaard.

[whoami]

In MS SQL Server kan je -geloof ik- gebruik maken van global variables. Variabelen declareren in je View kan niet.

[JaQ]

djluc schreef op 19 August 2003 @ 18:07:
[...]
Het kan natuurlijk ook zo zijn dat hij database onafhankelijk wil proggen, of in ieders geval volgens de SQL standaard.

nofi, maar dat gaat zeker ook lukken als ieder rdbms een ander dialect gebruikt.

[Verwijderd]

whoami schreef op 19 August 2003 @ 18:13:
In MS SQL Server kan je -geloof ik- gebruik maken van global variables. Variabelen declareren in je View kan niet.

Dit klopt.. In een CREATE VIEW kan je geen variabelen definieren en gebruiken. De beste oplossing om een stored procedure aan te maken die er uit ziet, zoals:

CREATE PROCEDURE naam AS

DECLARE @var
@var =
SELECT .....

[Chillz]

een procedure zou natuurlijk een mooie oplossing zijn...

ik zit echter gebonden aan Tabel of View,
omdat de enige twee objecten zijn die ik dan later weer in de rapportgenerator kan inlezen... tja, beperkingen he...

gebruik SQL Server btw

ik denk dat als variabelen in een View echt niet gaan werken dat ik dan toch maar gewoon de view moet gaan gebruiken met vaste waarden... en dan, zodra de 'variabele' waarden veranderd zijn, telkens aanpassen. zit niets anders op...

[whoami]

Chillz schreef op 20 August 2003 @ 09:03:
een procedure zou natuurlijk een mooie oplossing zijn...

ik zit echter gebonden aan Tabel of View,
omdat de enige twee objecten zijn die ik dan later weer in de rapportgenerator kan inlezen... tja, beperkingen he...

gebruik SQL Server btw

Kan je dan geen User Defined Function gebruiken die een TABLE returned? Die kan je dan ook in een FROM clausule van een SELECT query gebruiken.

[Verwijderd]

kan je in je view gewoon niet je stored proc oproepen waarin je je variable hebt gedeclareerd?

[whoami]

Verwijderd schreef op 20 August 2003 @ 09:35:
kan je in je view gewoon niet je stored proc oproepen waarin je je variable hebt gedeclareerd?

Een view kan alleen maar SELECT statements bevatten.

[Verwijderd]

Chillz schreef op 20 August 2003 @ 09:03:
een procedure zou natuurlijk een mooie oplossing zijn...

ik zit echter gebonden aan Tabel of View,
omdat de enige twee objecten zijn die ik dan later weer in de rapportgenerator kan inlezen... tja, beperkingen he...

gebruik SQL Server btw

ik denk dat als variabelen in een View echt niet gaan werken dat ik dan toch maar gewoon de view moet gaan gebruiken met vaste waarden... en dan, zodra de 'variabele' waarden veranderd zijn, telkens aanpassen. zit niets anders op...

Welke rapportgenerator gebruik je dan?
Met crystal reports kun je bijvoorbeeld wel degelijk de gegevens baseren op een stored procedure. Je moet dat alleen even in de instellingen aangeven

[Chillz]

Verwijderd schreef op 20 August 2003 @ 09:59:
Welke rapportgenerator gebruik je dan?
Met crystal reports kun je bijvoorbeeld wel degelijk de gegevens baseren op een stored procedure. Je moet dat alleen even in de instellingen aangeven

Cognos Improptu...

alleen tabellen en views
(weet niet of het aan het pakket ligt of aan de installatie, misschien is er alleen hiervoor betaald)

[whoami]

Je kan een UDF maken, en dan een view die die UDF gebruikt:

code:

CREATE FUNCTION blaat
RETURNS TABLE
AS

  DECLARE @blaat        INT

BEGIN

     SET @blaat = ....

     SELECT * FROM tabel
     WHERE tabel.id = @blaat

END
GO

CREATE VIEW vw_something
AS
SELECT * FROM blaat()
GO

[P_de_B]

Kun je niet gewoon een subquery gebruiken? De query die je nu gebruikt om de waarde aan de variabele toe te wijzen kun je ook in je gewone select gebruiken. Ik zie de reden niet waarom je dit met een variabele zou moeten doen.

[whoami]

P_de_B schreef op 20 augustus 2003 @ 11:54:
Kun je niet gewoon een subquery gebruiken? De query die je nu gebruikt om de waarde aan de variabele toe te wijzen kun je ook in je gewone select gebruiken. Ik zie de reden niet waarom je dit met een variabele zou moeten doen.

Dat is ook weer waar..... Ik had die query niet echt goed bekeken, maar het is idd goed op te lossen door gebruik te maken van een subquery.

code:

CREATE VIEW vw_blaat
as
SELECT ...
FROM ...
WHERE jaartal = (SELECT param.jaar FROM param .... )

[Chillz]

omdat de variabele ook IN de namen van kolommen en tabellen binnen mijn view voorkomt

bv. waarde variabele = 2003

tabelnaam = Unit_info_2003
kolomnaam = Unit_info_2003_kolom1

[P_de_B]

Hmm, ik bedenk me net dat dit alles een beetje tegen het principe van een view ingaat. Je zou gewoon moeten doen

SELECT * FROM vwMijnView
WHERE Jaartal = (SELECT [.. ] )

maar goed, dit is wel gemierenuek

[whoami]

Chillz schreef op 20 August 2003 @ 12:02:
omdat de variabele ook IN de namen van kolommen en tabellen binnen mijn view voorkomt

Ga je dan je SQL - string dynamisch gaan opbouwen ?

[P_de_B]

Chillz schreef op 20 August 2003 @ 12:02:
omdat de variabele ook IN de namen van kolommen en tabellen binnen mijn view voorkomt

bv. waarde variabele = 2003

tabelnaam = Unit_info_2003
kolomnaam = Unit_info_2003_kolom1

Oeps, tijd voor een redesign. Zoek eens wat info over database normalisatie, zoals je het nu hebt blijft problemen geven, daar kun je vanuit gaan. Daarbij komt dat je dynamic SQL zou moeten gebruiken als je het jaartal in als parameter voor de SELECT list wilt doorgeven. Dat kan ook niet in een view.

Als je niets kunt wijzigen aan het db schema zit er niets anders op dan een view voor elk jaar te maken.

[whoami]

P_de_B schreef op 20 augustus 2003 @ 12:06:
[...]

Als je niets kunt wijzigen aan het db schema zit er niets anders op dan een view voor elk jaar te maken.

Als het zo is, dan geloof ik dat hij met UDF's ook een oplossing kan maken.
Je kan nl. een UDF maken die een TABLE returned, en binnen die UDF kan je ook dynamic SQL gaan uitvoeren dacht ik.....
Die UDF kan je dan in een view gaan gebruiken. (Zoals ik al eerder gepost heb. Wel niet uitgetest).

[P_de_B]

whoami schreef op 20 augustus 2003 @ 12:09:
[...]


Als het zo is, dan geloof ik dat hij met UDF's ook een oplossing kan maken.
Je kan nl. een UDF maken die een TABLE returned, en binnen die UDF kan je ook dynamic SQL gaan uitvoeren dacht ik.....
Die UDF kan je dan in een view gaan gebruiken. (Zoals ik al eerder gepost heb. Wel niet uitgetest).

Goed idee, heb het even getest en dat gaat goed werken!

code:

Use pubs
GO

CREATE TABLE Settings (HasContract bit)

ALTER FUNCTION fngetAuthorsWithContract ()

RETURNS @au table (
    [au_id] [varchar](100)  ,
    [au_lname] [varchar] (40) ,
    [au_fname] [varchar] (20) ,
    [phone] [char] (12) ,
    [address] [varchar](50)  ,
    [city] [varchar] (20) ,
    [state] [char] (2) ,
    [zip] [char] (5)  ,
    [contract] [bit] 
)

AS

BEGIN
INSERT @au
 SELECT * FROM authors WHERE contract = (SELECT HasContract FROM Settings)
RETURN
END
GO


CREATE VIEW vwTesting

AS

SELECT * FROM pubs.dbo.fngetAuthorsWithContract()
GO


-- testen:
INSERT INTO Settings (HasContract) values (1)

SELECT * FROM  vwTesting

UPDATE Settings SET HasContract = 0

SELECT * FROM  vwTesting

Dit moet natuurlijk ook werken voor dynamische SQL enzo. Nogmaals goed idee whoami!

[ Voor 4% gewijzigd door P_de_B op 20-08-2003 12:27 ]