Wie user-abhängige Daten an View übergeben

[SneakL8]

Hallo Frickler,

danke für die Infos zu SP.
Aber diese SP müsste ich dann ja auch in der View verwenden und damit läge der Parameter in der View, an die ich keinen übergeben kann. Oder hab ich was übersehen?

Viele Grüße
Sneak-L8

[jobo]

Also nur weil man 2 gute Dinge kombiniert, SP und View, kommt nicht zwangsläufig was Gutes dabei raus.
Und ja, es gibt Fälle, wo man sich die Möglichkeiten einer SP zu nutze machen kann. Die sehe ich in diesem Fall aber nicht.

Ich verweise auf Beitrag 2. Das sollte ohne Nebenwirkungen funktionieren und entspricht dem normalen Vorgehen.

[SneakL8]

Hallo Jo,

danke für Deinen Hinweis, der Post von Frickler war schneller zu beantworten, daher hatte ich dazu zuerst geschrieben.

Jetzt konnte ich auch Deinen Vorschlag näher ansehen. Hab's ausprobiert. Ja, wen ich d.UserID aus der View mit ausgebe, dann kann ich darüber ebenfals filtern. Scheint auch nicht langsamer zu sein, als wenn die Bedingung direkt in der View angegeben wird. Ich hatte mich zuerst über das Wort "Parameter (von außen)" gewundert.

Aberso funktioniert's prima, auch wenn ich nun immer an die WHERE-Angabe bei der Nutzung der View denken muss - ja, an den Parameter oder ne Temp-Tabelle müsste ich auch denken...

Viele Grüße
Sneak-L8

[himitsu]

Es gibt auch DBMS, bei denen man Parameter an einen View übergeben kann.

Aber meißtens ist es so, dass der View die Daten für alle User gibt und man das Userabhängige dann über das WHERE des äußeren SELECTs rausfiltert.

Zitat von SneakL8:

Aber diese SP müsste ich dann ja auch in der View verwenden und damit läge der Parameter in der View, an die ich keinen übergeben kann. Oder hab ich was übersehen?

Jupp, indem du eben nicht den View verwendest, sondern direkt das Result der SP.
SELECT * FROM YourSP(Params) ,
bzw. siehe #6, falls es in diesem DBMS so gemacht werden muß.

Ich kenn ADS auch nicht, aber andere DBMS erlauben SP in mehreren Sprachen, wo man z.B. auch direkt ein SQL-Statement als Funktionsrumpf angeben kann.
Also die SP nur als eine Art Makro um das SELECT drumrum.

[hoika]

Hallo,
was ist denn bei Verwendung einer temporären Tabelle?
Was sind da Deine Probleme?

Müsste das nicht wie unten beschrieben gehen oder scheitert der ADS
daran, dass der View die temp. Tabelle nicht kennt.

http://devzone.advantagedatabase.com...statements.htm

[jobo]

Ist erledigt, eine Temptable ist unnötig:

Zitat von SneakL8:

..
Aberso funktioniert's prima, auch wenn ich nun immer an die WHERE-Angabe bei der Nutzung der View denken muss -
..

[hoika]

Hallo,

Zitat:

Scheint auch nicht langsamer zu sein, als wenn die Bedingung direkt in der View angegeben wird.

Ja, weil der View ja nur die Komplexität der Query versteckt,
aber intern trotzdem wie eine Query behandelt wird.

Ausnahme: materialized view (z.B. bei Oracle)
http://www.oracle.com/webfolder/tech...ion/index.html

[SneakL8]

@hoika

Ja, diese Beschreibung hatte ich auch gelesen. Aber da passiert alles im gleichen Fokus. Wenn ich die temp. Table im ARC in eienr View verwende, meckert er, dass er die Tabelle nicht kennt. Auch nicht, wenn ich vorher im SQL-Fenster des ARC die Tabele definiere. Zugriff im Programm klappt dann auch nicht.

Viele Grüße
Sneak-L8