Announcement

Collapse
No announcement yet.

Sind Views immer readonly?

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

  • Sind Views immer readonly?

    Ich habe in einer IB6 DB eine VIEW erstellt welche 3 Tabellen verbindet und diese mit einem Insert und einem Update Trigger versehen um sie editierbar zu machen. Wenn ich dies View nun an ein IBX-TIBTable binde, lässt sich diese trotzdem nicht auf readonly:=false setzen, die entsprechenden Schaltflächen eines dbnavigators werden also gesperrt. Wie kann ich die Möglichket der View-Trigger nutzen?<br>Peter

  • #2
    Hallo,

    mein letzter Einsatz dieser Technik war mit einer <b>TQuery</b>-Instanz und <b>RequestLive := True</b> erfolgreich. Mit IBX habe ich das aber bisher nicht ausprobiert

    Comment


    • #3
      Hallo,
      Ich denke TIBTable ist sowieso nicht der richtige Ansatz in einer C/S Umgebung, aber in TIBQuery kann ich sowas wie <b>RequestLive</b> oder <b>readonly</b> gar nichtmehr finden. Wie bekomme man also den UpDate / Insert Knopf eingeschaltet). <br>Wenn ich UpdateSQL verwenden muss, wo ist dann der Nutzen der Trigger in der View? <br> Gruß Peter

      Comment


      • #4
        Das Problem liegt wohl doch schon beim Interbase-Server. Ich habe versucht ein UPDATE-SQL auf die View loszulassen. Dieser wird mit der Meldung: view ist readonly o.ä. zurückgewiesen, obwohl für die view ein BeforUpdate-Trigger existiert. Also lautet die Frage: wie macht man Interbase klar, das die View nicht readonly ist? <br>Pete

        Comment


        • #5
          Hallo,

          der folgende Auszug stammt aus einem Artikel von mir aus DER ENTWICKLER (1997):

          Immer dann, wenn der InterBase einem View zugeordnete Trigger vorfindet, werden die INSERT/UPDATE/DELETE-Aufrufe nur noch von den Triggern behandelt und nicht mehr bis zum View durchgereicht. Dies gilt auch dann, wenn das View nicht Read-Only ist, d.h. durch das Zuordnen von Triggern erhalten Sie die vollständige Kontrolle darüber, was über den View in der Datenbank eingetragen werden soll.
          Im Handbuch InterBase 5.0 Data Definition Guide findet sich dazu auf den Seiten 178-179 das folgende Beispiel (ich habe es nur für den Aufruf aus dem SQL-Explorer heraus modifiziert):
          <pre>
          /* SQL-Explorer-Script */
          /* Anw.-Begrenzer: ^ */
          /* Beispiel aus InterBase Data Definition Guide */

          CREATE TABLE Table1(
          ColA INTEGER NOT NULL,
          ColB VARCHAR(20),
          CONSTRAINT PK_Table1 PRIMARY KEY(ColA)
          )
          ^

          CREATE TABLE Table2(
          ColA INTEGER NOT NULL,
          ColC VARCHAR(20),
          CONSTRAINT PK_Table2 PRIMARY KEY(ColA)
          )
          ^

          /* Read-Only-View */
          CREATE VIEW TableView AS
          SELECT Table1.ColA, Table1.ColB, Table2.ColC
          FROM Table1, Table2
          WHERE Table1.ColA = Table2.ColA
          ^

          CREATE TRIGGER TableView_Delete FOR TableView BEFORE DELETE AS
          BEGIN
          DELETE FROM Table1 WHERE ColA = OLD.ColA;
          DELETE FROM Table2 WHERE ColA = OLD.ColA;
          END
          ^

          CREATE TRIGGER TableView_Update FOR TableView BEFORE UPDATE AS
          BEGIN
          UPDATE Table1 SET ColA = NEW.ColA;
          UPDATE Table2 SET ColC = NEW.ColC WHERE ColA = OLD.ColA;
          END
          ^

          CREATE TRIGGER TableView_Insert FOR TableView BEFORE INSERT AS
          BEGIN
          INSERT INTO Table1 VALUES (NEW.ColA,NEW.ColB);
          INSERT INTO Table2 VALUES (NEW.ColA,NEW.ColC);
          END
          ^
          </pre>
          Da die Trigger die von Delphi zurückgeschickten Informationen auf die beteiligten Tabellen aufteilen, kann sich TQuery genau so verhalten wie bei einer Abfrage einer einzelnen Tabelle

          Comment


          • #6
            Danke für das Beispiel. Es läuft auch auf dem IB6. Irgendwas muss also in meiner, etwas komlexeren, Konstallation anders sein. Ich werde mich also ans debuggen begeben. <br>
            Pete

            Comment


            • #7
              kaum sind 1 1/2 Tage mit haareraufen und debuggen vergangen, schon zeigt sich der Fehler:<br>
              Ich hab bei der Definition der View folgende Syntax benutzt:<br>
              create view_xx(<br>
              alias1<br>
              : <br>
              ) as<br>
              selecet<br>
              tabelle.feld alias1 <br>
              :<br>
              Die Verwendung des alias im select Teil ist überflüssig, wird aber bei der Definition der View akzeptiert. Sobald nun der Trigger auf den Aliasnamen zugreift ergeben sich solch aussagekräftige Fehlermeldungen wie: The cursor identified in the update or delete statement is not positioned on a row.
              no current record for fetch operation.
              attempted update of read-only column.<br>
              (in einem insert statement versteht sich). <br>
              Insgesamt scheinen die Fehlermeldungen im IB6 sowieso mit PGP ermittel zu werden. Wenn man den alias im select-teil weglässt funktionieren die Trigger!<br>
              Pete

              Comment

              Working...
              X