Oracle: 'SELECT owner.tablename ...'

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo!

Ich hab in einer Oracle-Datenbank als Benutzer mit Admin-Rechten (sagen wir dieser heißt „kinguser“) eine Tabelle angelegt („mytable“) und nötigen Zugriffsrechte für die Tabelle vergeben.
Mit einem Standardbenutzer ohne Admin-Rechte soll nun darauf zugegriffen werden. Das funktioniert aber nur wenn ich das SELECT-Statement folgendermaßen formuliere:

SELECT \* FROM kinguser.mytable

Versuche ich es allerdings mit:

SELECT \* FROM mytable

kommt nur die Meldung: „Table or view does not exist“

Warum ist das so bzw. wie kann ich das ändern?

Danke und lg
Daniel

#2

Warum ist das so bzw. wie kann ich das ändern?

Danke und lg
Daniel

  • Das ist so, weil sich dein 2. Benutzer in seinem eigenem Schema einloggt.

  • Das kannst du ändern, wenn du

a) einen Session Trigger absetzt : ALTER SESSION SET DEFAULT_SCHEMA=‚ZIELSCHEMA‘

b) oder dies sonstwie, z.b. in deinem Applikationsserver, falls vorhanden, konfigurierts beim Create Session

c) Alternativ könntest du auch mit Synonymen arbeiten, ich persönlich bin allerdings nicht ein Fan davon…

Gruss

#3

Vielen Dank für die Vorschläge, ich hab’s mit einem Synonym gelöst, erschien mir als die einfachste Möglichkeit.

Wieso hältst du eigentlich von Synonymen nichts, gibt es da einen bestimmten Nachteil?

lg Daniel

#4

Hi!

c) Alternativ könntest du auch mit Synonymen arbeiten, ich
persönlich bin allerdings nicht ein Fan davon…

DAS würde mich jetzt persönlich interessieren (weil ich ein Fan von denen bin :wink:

Grüße,
Tomh

#5

Hallo Tomh

Nun, Die Lösung mit der Änderung des Default_Schemas ist „weniger komplex“. Synonyme erzeugen eine weitere Schicht Abhängigkeit (Du musst sie anlegen/pflegen/warten). Ich bin nicht generell gegen Synonyme, wir haben dies früher oft benutzt, die Lösung mit der Änderung des DEFUALT_SCHEMA’s ist einfach eleganter, vor allem , wenn du komplexere Strukturen betreuen musst.

Gruss

#6

Hallo Daniel,

Siehe meine Antwort an Tomh. Meiner Meinung nach ist es eben die nicht die einfachere Lösung.

Gruss

#7

Hi!

Synonyme erzeugen eine weitere Schicht
Abhängigkeit (Du musst sie anlegen/pflegen/warten).

Und genau deswegen ist alles schön definiert, Objekte von verschiedenen Schemen, Remote-Datenbanken und Fremddatenbanken fließen ein, über langfristig verwendbare Applikationen (ich rede hier von Zeiträumen von 40-50 Jahren) können sich DB-Definitionen ändern - die Applikation bleibt unberührt, es wird lediglich das Synonym „erneuert“ …

Ich bin
nicht generell gegen Synonyme, wir haben dies früher oft
benutzt

Ab welcher Version gab’s eigentlich das DEFAULT_SCHEMA?? Ich habe erst bei der 9er zum ersten Mal davon gehört …

die Lösung mit der Änderung des DEFUALT_SCHEMA’s ist
einfach eleganter, vor allem , wenn du komplexere Strukturen
betreuen musst.

Hm, ich würde eher sagen: Wie man es gewohnt ist. Sobald mehrere Schemen miteinfließen (was bis jetzt bei meinen Projekten IMMER der Fall war), wird’s mit dem DEFAULT_SCHEMA komplexer (meine ganz persönliche Meinung - und davon bringt mich niemand ab :wink:

Grüße,
Tomh

#8

Hi!

Synonyme erzeugen eine weitere Schicht
Abhängigkeit (Du musst sie anlegen/pflegen/warten).

Und genau deswegen ist alles schön definiert, Objekte von
verschiedenen Schemen, Remote-Datenbanken und Fremddatenbanken
fließen ein, über langfristig verwendbare Applikationen (ich
rede hier von Zeiträumen von 40-50 Jahren) können sich
DB-Definitionen ändern - die Applikation bleibt unberührt, es
wird lediglich das Synonym „erneuert“ …

  • ja Richtig…ein sauberes Konfigurationsmanagement ist IMMEER Voraussetzung für einen sauberen Betrieb (unter anderem)…ich sage ja nur, dass du ohne Synonyme weniger „Verwaltungsaufwand“ hast.

Ich bin
nicht generell gegen Synonyme, wir haben dies früher oft
benutzt

Ab welcher Version gab’s eigentlich das DEFAULT_SCHEMA?? Ich
habe erst bei der 9er zum ersten Mal davon gehört …

  • ja, genau

die Lösung mit der Änderung des DEFUALT_SCHEMA’s ist
einfach eleganter, vor allem , wenn du komplexere Strukturen
betreuen musst.

Hm, ich würde eher sagen: Wie man es gewohnt ist. Sobald
mehrere Schemen miteinfließen (was bis jetzt bei meinen
Projekten IMMER der Fall war), wird’s mit dem DEFAULT_SCHEMA
komplexer (meine ganz persönliche Meinung - und davon bringt
mich niemand ab :wink:

  • Auch wir haben praktisch immer n Schema im Einsatz, klar, soweit aber kein Problem damit. Wir entiwckln aber so, dass *alle* Zugriffe
    des Clients (in der Regel Appliaktiosserver) über Packages gekapselt werden, und dieses Interface ist in einem Schema konzentriert.
  • Es gibt auch den Fall, dass mehrere Applikationen auf dieselbe Datenbank, aber unterscheidliche Schema zugreifen, aber auch dies ist kein Problem, da die Applikationen jeweils eigene Applikationsserver
    verwenden.

und davon bringt

mich niemand ab :wink:

Will ich ja auch nicht…Oracle stellt uns Werkzeuge zu Verfügung…jede Menge…und alles hat seine Berechtigung

(Aussser Trigger :smile:)

Grüße,
Tomh

Grüsse,
Ulrich

#9

Hi!

*alle* Zugriffe
des Clients (in der Regel Appliaktiosserver) über Packages
gekapselt werden, und dieses Interface ist in einem Schema
konzentriert.

*grmpf* … genau DIESE Idee haben wir unserem Oberguru (technischer Scheffe) ganz schnell wieder ausgetrieben :wink:

und alles hat seine Berechtigung

(Aussser Trigger :smile:)

In die Ecke mit Dir, Ungläubiger!

SQL\>alter user Ulrich account lock;

User altered.

Grüße,
Tomh

#10

Hi!

*alle* Zugriffe
des Clients (in der Regel Appliaktiosserver) über Packages
gekapselt werden, und dieses Interface ist in einem Schema
konzentriert.

*grmpf* … genau DIESE Idee haben wir unserem Oberguru
(technischer Scheffe) ganz schnell wieder ausgetrieben :wink:

–> Und warum dies ?

und alles hat seine Berechtigung

(Aussser Trigger :smile:)

In die Ecke mit Dir, Ungläubiger!

SQL>alter user Ulrich account lock;

User altered.

-)

Grüße,
Tomh

#11

Hi!

*grmpf* … genau DIESE Idee haben wir unserem Oberguru
(technischer Scheffe) ganz schnell wieder ausgetrieben :wink:

–> Und warum dies ?

Mitten im Projekt.

  • bestehende Software sollte angepaßt werden (ca. 1000 Forms und Reports und dementsprechend jede Menge DB-Objekte)
  • schlicht und einfach: keine Zeit und keine Resourcen für diesen Schritt

Eine Überlegung war es allemal Wert, nur sollte dies am ANFANG festgelegt werden, und nicht nach ein paar Jahren Entwicklung, wo große Teile der Applikation noch unter Forms 4.5 auf einer 7er DB entwickelt wurden (man merkt, das Projekt läuft schon ein paar Jährchen und dementsprechend kann man sich den Umfang vorstellen) und bereits einige Jahre im Echtbetrieb waren bzw. noch immer sind.

Grüße,
Tomh

#12
  • Ja, dass vestehe ich :smile:. In solch einem Fall sind Synonyme sicher eine Alternative.

Grüsse
Ulrich