Announcement

Collapse
No announcement yet.

Select auf View eines anderen Schemas

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Select auf View eines anderen Schemas

    Hallo,
    ich habe folgende Frage:

    Ich habe zwei Schemas "PROD" und "TEST", die beide die gleichen Tabellen, aber unterschiedliche Daten haben.
    PROD hat eine View "V1" und per "GRANT SELECT ON V1 TO TEST" hat PROD an TEST das Leserecht gegeben.

    Wenn ich mich im TOAD als TEST einlogge und "select * from PROD.V1" ausführe, sehe ich die erwarteten Daten von PROD1. Mache ich das gleiche über .NET (z.B über den Server-Explorer in Visual Studio, egal ob mit MS oder Oracle-Treiber), sehe ich die Daten aus dem TEST(!) - Schema.

    Ich bin einigermaßen verwirrt. Es darf doch wohl keinen Unterschied machen, ob ich per OCI (Toad) oder .NET die Query absetze, oder? Was sollte denn das "richtige" Verhalten sein?

    Gruss,
    Kaggi

  • #2
    Das Verhalten von Toad ist das korrekte. Zwei Fragen:
    - Schreibst Du auch in deinem .Net Programm den Schemanamen vor die View so wie in Toad?
    - Verwendest Du den original Oracletreiber oder den von Microsoft? Falls letzteres der Fall ist, solltest Du unbedingt den Oracletreiber verwenden.

    Dim
    Zitat Tom Kyte:
    I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

    Comment


    • #3
      Originally posted by dimitri View Post
      Das Verhalten von Toad ist das korrekte. Zwei Fragen:
      - Schreibst Du auch in deinem .Net Programm den Schemanamen vor die View so wie in Toad?
      - Verwendest Du den original Oracletreiber oder den von Microsoft? Falls letzteres der Fall ist, solltest Du unbedingt den Oracletreiber verwenden.

      Dim
      Hallo Dimitri,
      danke für die Antwort. Zu den beiden Fragen:

      1. Ja, ich schreibe in beiden Fällen den Schemanamen hin (PROD.V1). Schon deshalb, weil es V1 im TEST-Schema gar nicht gibt.

      2. Es ist egal, welchen Treiber ich verwende. Sowohl Oracle als auch Microsoft ziehen die Daten aus dem TEST-Schema

      Ich habe noch einen weiteren Test gemacht und bei Definition der View im PROD - Schema immer nochmal explizit die gejointen Tabellen mit PROD.XXX statt nur XXX benannt. So will ich .NET zwingen, wirklich ins PROD-Schema zu schauen. Und siehe da - nun beschwert sich .NET über fehlende Zugriffsrechte der darunterliegenden Tabellen.

      Aber das wollte ich ja gerade mit der View umgehen. Das TEST-Schema soll nur die über die View gefilterten PROD-Daten sehen und kein GRANT SELECT auf die PROD-Tabellen erhalten...

      Noch ne Idee, wie man das löst?

      Gruss,
      Kaggi

      Comment


      • #4
        Also ich fasse mal zusammen:
        - Im TEST Schema gibt es kein Objekt (View oder tabelle) mit dem namen V1
        - Du meldest Dich im .Net Programm mit dem TEST User an, selectierst auf PROD.V1 und bekommst Daten aus TEST zu sehen

        Da das technisch jeglicher Logik widerspricht, muss der Fehler woanders sein.
        Bist Du dir sicher, dass Die Daten aus TEST sind? Falls möglich leere doch mal die entsprechenden Tabellen in TEST oder benenne die Tabellen um.
        Bist Du sicher, dass Du dich an die richtige Instanz anmeldest oder gibt es noch andere Instanzen mit diesem Aufbau?

        Dim
        Zitat Tom Kyte:
        I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

        Comment


        • #5
          So,
          nochmal ganz gründlich gemacht:

          > Im TEST Schema gibt es kein Objekt (View oder tabelle) mit dem namen V1
          Korrekt. Select auf TEST.V1 gibt ORA (Tabelle oder View nicht vorhanden)

          TOAD als TEST
          "Select * from PROD.V1" liefert 3 Datensätze

          Visual Studio als TEST, Oracle Treiber
          "Select * from PROD.V1" liefert 100 (andere Test-) Datensätze

          > Da das technisch jeglicher Logik widerspricht, muss der Fehler woanders sein.
          Eigentlich ja - aber es gibt nur eine Datenbank mit PROD-Schema.

          Tabellen kann ich momentan nicht so einfach machen...
          Es ist aber zu sehen, dass .NET die hinter der View stehende Query auf sein eigenes Schema laufen läßt.

          Comment


          • #6
            Problem gelöst

            Hallo,
            die Ursache für das Problem wurde gefunden, hier ist des Rätsels Lösung:

            Die Ursache liegt im Oracle-Client. Verbunden wird sich mit einer 10.2 Datenbank.

            Die .NET EXE nutzte einen 9er Client und zeigte den Fehler. Läuft sie mit einem 10er Client, kommen die korrekten Daten.
            Mit TOAD verhält es sich exakt genauso: 9er Client falsche Daten, 10er Client korrekte Daten.

            Zwar sagt Oracle, dass 9er Client und 10er RDBMS alles kein Problem sei (http://www.oracle.com/technology/tec...q.html#diffver), aber da ist wohl eher der Wunsch Vater des Gedanken.

            Hope that helps.

            Comment

            Working...
            X