SQL-View mit ALIAS

[Fuerchau]

Da habe ich nun eine Altanwendung (wirklich alt), die sehr gerne mit Teildateien in den Daten arbeitet.
Nun ja, per CREATE ALIAS kann man einer Teildatei einen eigenen SQL-Namen verpassen und per SQL auch darauf zugreifen.
Hier gehts nun um eine ODBC-Abfrage per Excel. Um es dem Enduser nun einfacher zu machen, wollte ich gerne eine View erstellen, die diesen Alias enthält.

Leider weigert sich SQL, die View zu erstellen, mit dem lapidaren Hinweis:

Nachrichten-ID . . . . : SQL7030 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Diagnose
Sendedatum . . . . . . : 09.03.11 Sendezeit . . . . . . : 13:40:35

Nachricht . . . : Aliasname REPOJJVW für Tabelle REPOJJ in DIDTA ist für die
Anweisung nicht gültig.
Ursache . . . . : Die SQL-Anweisung kann nicht für Aliasname REPOJJVW
ausgeführt werden, da der Aliasname auf eine Teildatei der Tabelle REPOJJ in
Schema DIDTA verweist.
Fehlerbeseitigung: Eine gültige Tabelle oder einen Aliasnamen angeben, der
nicht auf eine Teildatei verweist. Die Anforderung wiederholen.

Wofür brauch ich denn sonst den Alias, wenn nicht genau für sowas ?

Führe ich den (sehr komplexen) SQL direkt aus, läuft er auch problemlos.
Nur leider hilft mir das beim Excel-Import mit MS-Query nicht, da bei "nicht grafisch darstellbaren" Abfragen, "Parameter nicht erlaubt" sind.

Soviel zum Thema SQL.

[Robi]

Hi,

Schlechte Nachricht

http://newsolutions.de/forum-systemi...teildatei.html

Gruß
Robi

[Fuerchau]

Das war mir ja bekannt, aber es gibt doch keinen Grund, einen ALIAS in einer View abzulehen, im direkten SQL aber zu akzeptieren.
Wo liegt denn da der Unterschied ?

[andreaspr@aon.at]

Hallo Baldur,

kommt auch nicht oft vor, dass der Meister ein Thema erstellst

Ich verwende bei Excel für Enduser immer Stored Procedures oder wenns ein Select sein muss eine Table Function.

[Fuerchau]

Wenn da die gewissen Einschränkungen der Altanwendung nicht währen, eben die Teildateien.

Der Kunde ist aber nun zufrieden.

Auf der AS/400 wird per CLP mit CMD, QMQRY und Query/400 eine simple Ausgabedatei erstellt, die dieser sich dann mit Excel abholt.

Jetzt sagt nicht, das ist zu kompliziert.
Das CMD prompted eine Selektion mit Ausgabe einer Datei per QM-Query, das Query hat diese als erste Datei mit ein paar wweiteren, wird auch noch mit RCDSLT(*YES) gestartet (ist nötig, da der Anwender das Query gerne jederzeit selber noch ändern möchte).

Hauptsache es läuft...

[BenderD]

1. macht man sowas nicht!
2. lässt man sowas besser!
3. hält man sich an 1. und 2.!

Man kann natürlich erst die View bauen und dann den alias auf die View setzen und dort wieder ein Member angeben, was dann das Member der Table meint.

Aber frage mich keiner, wie man dann das 2. Member von A mit dem 286. Member von B verjoinen soll, ich halte mich nämlich seit 20 Jahren an 1., 2. und 3.

D*B

[Fuerchau]

Normalerweise würde ich ja sowas auch nicht machen, aber die Altanwendung läuft leider so.
An die Teildatei kommt man per SQL nur über ein Alias auf diese.
Ein Alias auf eine Teildatei, die nicht die 1. ist, lässt sich aber nur in direktem SQL, nicht aber in einer View verwenden.
Was immer sich die IBM dabei gedacht hat, bisher konnte ich eigentlichen jeden beliebigen SQL auch als View erstellen (außer order by halt).
Es besteht also technisch überhaupt kein Grund, das zu verweigern.