Announcement

Collapse
No announcement yet.

Schemabinding über 2 Datenbanken

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

  • Schemabinding über 2 Datenbanken

    Hallo Comm,

    mein Ausgangspunkt sind 2 Datenbanken, DB1 & Db2. Auf dem DB2 befindet sich eine View1. Auf DB1 befindet sich eine Tabelle1 & eine View2 bestehend aus DB1.Tabelle1 & DB2.View1 (JOIN).

    Da ich über ein GridView auf View2 zugreife und dort Änderungen vornehmen möchte, die in Tabelle1 gespeichert werden sollen, stellt sich mir die folgende Fage:

    Funktioniert das SCHEMABINDING CREATE/ALTER VIEW über 2 Datenbanken?

    Mein SQL String liefert egal wie ich ihn drehe immer Fehlermeldung über ungültige Objekte:

    Code:
    ALTER VIEW DB1.v_MatStamm_DAS WITH SCHEMABINDING AS
    SELECT     DAS_SP_MATERIALSTAMM.MATNR, DAS_SP_MATERIALSTAMM.ZZMM_BEZLR, DAS_SP_MATERIALSTAMM.ZZMM_PROD, DAS_SP_MATERIALSTAMM.MTART, DAS_SP_MATERIALSTAMM.EAN11, DAS_SP_MATERIALSTAMM.MAKTX
    FROM         SAPDATEN.DAS_SP_MATERIALSTAMM
    Ungültiger Objektname 'SAPDATEN.DAS_SP_MATERIALSTAMM'

    Kann mir an dieser Stelle jemand weiter helfen oder zumindest bestätigen/verneinen, das SCHEMABINDING über 2 Datenbanken funktioniert?

    Viele Grüße
    Strasser

  • #2
    Hallo Strasser,

    Nein, ein Datenbank-übergeifendens Schema-Binding geht nicht. Eine Datenbank-übergreifende Besitzverkettung geht normalerweise auch nicht, man muss es explizit aktivieren und davon wir abgeraten.

    Wozu brauchst Du das den, Du willst doch nur Daten ändern? Schema-Binding verhindert nur Design-Änderungen (DML).

    Wäre auch "lustig", wenn das ginge, am besten noch mit wechsel-seitigen Bindungen; dann kann man nie ein Datenbank auf einen anderen Server rücksichern etc., weil die Prüfung fehl schlägt
    Olaf Helper

    <Blog> <Xing>
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich

    Comment


    • #3
      Hallo O. Helper

      Wozu brauch ich das?:

      Wie gesagt, ich greife mit einem Gridview auf eine SQL-View zu. Im GridView klicke ich nun auf Bearbeiten - gebe einen Wert in eine der Zellen ein - und klicke auf aktualisieren. (Der eingegebene Wert soll gespeichert werden, schlussendlich in einer der Tabellen die dem SQL-View zugrunde liegen)
      Daraufhin erfolgt im Sharepoint bzw meinem Webpart die ultra aussagefähige Fehlermeldung:

      Es ist ein unerwarteter Fehler aufgetreten.

      Wow

      Wenn ich das selbe auf eine -SQLTabelle durchführe klappt alles wunderbar. Warum keine Tabelle? Ich brauch die View da ich aus beiden Datenbanken 2 Tabellen/Views joine.

      Durch diverse Recherchen bin ich irgendwann darauf gestoßen das man die View indizieren muss für Änderungen, was wiederum nur geht wenn man diese mit SCHEMABINING erstellt.

      Da ich wohl den Wald vor lauter Bäumen nicht mehr sehe, für einen alternativen Lösungsansatz wäre ich dankbar.

      Gruß & Danke
      Strasser


      ps: Kann man über SQL-Synonyme irgendwas erreichen? Hier kann man ja scheinbar Objekte anderer Datenbanken in einer anderen "aufrufen". Habe ich noch nie mit gearbeitet vielleicht auch völlig daneben.

      Comment


      • #4
        Sieht aus, als benötige das Gridview einen primary/unique key für das Update. Wenn jetzt die View keinen hat, vielleicht kann man ihn im gridview-Objekt setzen? Wäre das Problem ein anderes, könnte man über InsteadOf-Trigger in der View nachdenken, aber wenn Änderungen in der View selber im SQL-ManagementStudio kein Problem sind, ist der Verdacht bezüglich Index schon stark gegeben. Lösung habe ich dafür leider im Moment keine und ob das mit Synonyms geht wage ich mal zu bezweifeln. Bin schon auf die Lösung gespannt.

        bye,
        Helmut

        Comment


        • #5
          Viel Wirbel um Nichts....

          tja, am liebsten würde ich gar nicht mehr Antworten aber.... was solls,

          Nachdem ich mich im Schemabinding festgebissen hatte, habe ich das Thema beiseite gelegt (gedanklich ) und mich mit der intensiven Fehlersuche des Codings beschäftigt....

          Manchmal ist es halt sehr einfach.... Wald und Bäume uns so wie ich schon vermutete....

          Code:
          tBoxArtNr.DataField = "ArtNr"
                      tBoxArtNr.HeaderText = "ArtNr"
                      tBoxArtNr.ReadOnly = True
          Tja mein Boundfield "ArtNr" hatte ich zuvor auf ReadOnly gesetzt, damit dieses im GridView NICHT in den Bearbeitungsmodus gesetzt werden kann, schließlich handelt es sich dabei um den Key. Setze ich das Ganze auf FALSE, kann ich meine Updates wunderbar durchführen. Letzendlich wird das KeyFeld zwar in den BearbeitenModus gesetzt, man kann es inhaltlich aber nicht beeinflussen. Warum dieses Feld auf ReadOnly = False stehen muss ist mir tatsächlich nicht klar, denn in in meinem Command:

          Code:
          aSQLDS.UpdateCommand = "Update v_XXXXXXXX SET Relevanz=@Relevanz, MATNR=@MATNR Where ArtNr=@ArtNr"
          greife ich doch nicht "schreibend" auf ArtNr zu!?. Nunja, man kann nicht alles haben.

          Fazit: Views kann man allen Anschein nach ohne Probleme, auf die gewünschte Art & Weise, ändern, und vor allem ohne sich Stunden mit dem Thema Schemabinding auseinander zu setzen. Naja schaden tuts nicht, so ganz geläufig war mir dieses Thema nämlich nicht.

          In diesem Sinne, Problem gelöst, vielen Dank an alle Helfer

          Gruß
          Strasser

          Comment

          Working...
          X