Announcement

Collapse
No announcement yet.

Problem mit SQL Server 7 und BDE

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

  • Problem mit SQL Server 7 und BDE

    Hallo,

    Folgendes Problem: Datenbankanwendung mit BDE und SQL Server 7. Der erste Rechner startet eine Transaktion mit Database1.Starttransaction und fügt in einem DBGrid eine neue Zeile ein. Der zweite Rechner möchte einen Datensatz (ein anderer Datensatz als Rechner 1 im Zugriff hat) mit einer ganzen Menge von Detailtabellen kopieren. Dies funktioniert nicht bzw. nur extrem langsam. Erst wenn der erste Rechner seine Transaktion mit einem Database1.Commit beendet geht der Kopiervorgang wieder schnell. Warum ist das so? Ist das der Grund, warum man die BDE nicht mit SQL 7 benutzen soll? Ansonsten läuft das Programm ohne Probleme. Nur bei einer nichtabgeschlossenen Transaktion werden die anderen Rechner bei Datenintensiven Operationen sehr langsam und zuweilen kommt auch ein Timeout. Wer weiß Rat.

    Stefan

  • #2

    Comment


    • #3
      Hallo,

      der Microsoft <b>SQL Server 7</b> verwendet im Gegensatz zum <b>InterBase</b> keine Multigenerationen-Architektur. Somit gilt die Regel <i>"Lesezugriffe behindern keine Schreibzugriffe und Schreibzugriffe behindern keine Lesezugriffe"</i> nur für den InterBase, aber nicht für den SQL Server 7. Die allesentscheidende Frage ist: Mit welchem <i>Transaction Isolation Level</i> (TIL) wird der SQL Server 7 betrieben? Wenn <b>SERIALIZABLE</b> verwendet wird, können Datenbankseitensperren und Index-Sperren auftreten. Wird <b>REPEATABLEREAD</b> verwendet, entfernt der Server erst beim Ende der eigenen Transaktion alle S-Locks (Shared Locks alias Lese-Sperre).

      Da es diese Beschränkungen gibt, stehen nur 3 Möglichkeiten zur Beseitigung dieses Problems zur Verfügung: <br>
      1. Es wird ein geeigneter <b>TIL</b> ausgewählt <br>
      2. Es wird je SQL-Anweisung der geeignete <b>TIL-Hint</b> übergeben <br>
      3. Das eigene Programm verwendet nur sehr kurze Transaktionszeiten (der Anwender darf <b>niemals</b> die Länge einer Transaktion bestimmen).

      Nur die 3. Möglichkeit ist universell geeignet - die beiden ersten Alternativen sind nur in bestimmten Situationen hilfreich

      Comment


      • #4
        Hallo Andreas,

        das Problem tritt mit allen TransIsolation-Einstellungen(DirtyRead, ReadCommitted, RepeatableRead) auf. Serializable gibt es bei mir nicht. Was ist ein TIL-Hint? Wie kann ich denn Datenbankänderungen ohne Transaktion wieder rückgängig machen? Tritt das Problem mit ADO-Treibern auch auf? Mit SQL Anywhere von Sybase gab es diesbezüglich keine Probleme. Ist SQL Server 7 diesbezüglich wirklich so schlecht?

        Stefa

        Comment


        • #5
          Hallo,

          ein <b>TIL-Hint</b> ist ein vom SQL Server 7 unterstützter Weg, den Transaction Isolation Level (TIL) nur für eine einzige SQL-Anweisungen zu ändern.

          Die SQL-Links der BDE setzen auf die "alten" DBLib-DLLs des SQL Server 6.5 auf. Microsoft hat diese Schnittstelle nicht für die neue Version aktualisiert, so dass Borland+Microsoft generell den Einsatz der neuen OLE DB-Treiber (ADO) empfehlen. Leider hat die Version 6.5 des SQL Servers nicht alle TIL unterstützt - so das es durchaus hier zu Problemen kommen könnte (allerdings habe ich mit dem 6.5er keine Erfahrungen). Alle meine Erfahrungen mit dem SQL Server habe ich nur mit der 7er Version über ADO gemacht - zur BDE kann ich an dieser Stelle nichts sagen.

          Werden explizite Transaktionen verwendet, muss man unabhängig vom Zugriffsweg in jedem Fall dafür sorgen, das die Zeitdauer bis zum COMMIT/ROLLBACK so kurz wie möglich ist (d.h. der Anwender darf diesen Zeitrahmen nicht bestimmen). Somit müssen andere Anwendungen nur kurze Zeit warten, bis eine eventuell gesetzte Datenbankseite vom Server wieder entsperrt wird

          Comment

          Working...
          X