Announcement

Collapse
No announcement yet.

Umlautprobleme bei InterBase über ADO

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

  • Umlautprobleme bei InterBase über ADO

    Hallo zusammen!<br>
    <br>
    Es gibt hier schon ein paar Postings zum Thema "Eine Anwendung - mehrere Datenbankserver". Eine Entscheidung zum Thema ist demnächst bei mir auch fällig.<br>
    <br>
    Ich persönlich favorisiere als Backend InterBase bzw. Firebird. Viele Kunden haben bereits MS-SQL oder Oracle laufen und möchten - aus welchen Gründen auch immer - keinen weiteren Datenbankserver installieren.<br><br>
    Daher teste ich gerade die Performance von DB-Operationen auf Interbase und MS-SQL auf identischer Codebasis via ADO und im Vergleich zu IBX. Die Geschwindigkeit bei ca. 17.000 Inserts via ADO hält sich bei beiden Datenbankservern ungefähr die Waage (ca. 21 Sekunden). IBX ist einen Tick schneller...<br>
    <br>
    Nur habe ich im Moment das Problem, keine Stringwerte mit Umlauten in eine InterBase-Tabelle via ADO einfügen zu können. Bei einer Verbindung mit MS-SQL gibt es mit identischem Code keine Probleme. Es liegt wohl daran, dass im Gegensatz zu TIBDatabase bei TADOConnection kein Zeichensatz explizit angegeben werden kann.<br><br>
    In der InterBase-Datenbank wurden alle String-Felder mit einer Domain erzeugt:<br>
    create domain string250 as varchar(250) character set ISO8859_1 collate DE_DE<br>
    <br>
    Bei einer Verbindung über IBX wird dem TIBDatabase-Objekt der Parameter "lc_type=..." übergeben. Bei TADOConnection ist das ja nicht möglich.<br>
    <br>
    Wie kann ich über ADO trotzdem die InterBase-Datenbank mit dem richtigen Zeichensatz ansprechen?<br>
    <br>
    Vielen Dank,<br>
    Christian

  • #2
    Hallo,

    &gt;Es liegt wohl daran, dass im Gegensatz zu TIBDatabase bei <br>
    &gt;TADOConnection kein Zeichensatz explizit angegeben werden kann.

    diese Aussage ist so nicht korrekt, denn für die Verbindung zur Datenbank ist <b>nicht</b> <i>TADOConnection</i> (oder das darunterliegende native <i>Connection</i>-Objekt von ADO) zuständig, sondern statt dessen der eingebunden <b>OLE DB Provider</b>. Wie das folgende Beispiel für den <i>SIBProvider</i> zeigt, stellt dieser für den Zugriff auf eine InterBase-Datenbank die Eigenschaft <b>CHARACTER SET</b> zur Verfügung:
    <pre>
    object ADOConnectionMain: TADOConnection
    ConnectionString =
    'Provider=sibprovi.SIBProvider;Password=masterkey; User ID=SYSDBA;' +
    'Data Source=C:\Database\SIBProv.gdb;Location=localhost: ;Extended' +
    ' Properties="";Persist Encrypted=True;Encrypt Password=True;Mask' +
    ' Password=True;Cache Authentication=True;Persist Security Info=T' +
    'rue;CHARACTER SET="";ROLE=""'
    IsolationLevel = ilReadCommitted
    LoginPrompt = False
    Provider = 'sibprovi.SIBProvider'
    Left = 8
    Top = 8
    end
    </pre>
    &gt;Wie kann ich über ADO trotzdem die InterBase-Datenbank mit dem richtigen Zeichensatz ansprechen?

    Welcher OLE DB Provider wird denn genutzt? In der Dokumentation dieses Providers muss die notwendige Syntax gesucht werden, über die der Zeichensatz definiert werden kann.

    Comment


    • #3
      Hallo Herr Kosch,<br>
      <br>
      vielen Dank für Ihre rasche Rückmeldung.<br>
      Ich nutze derzeit als Provider "IbOleDb 1.6" von Oledb.net.<br><br>Ich möchte erst ausgiebig testen, ob sich meine Anwendung so gestalten lässt, dass Interbase, MS-SQL und Oracle unterstützt werden. Da ich keine Stored Procedures und spezielle Features der einzelnen DB-Server benötige, müsste es eigentlich klappen.<br><br>
      Mit welchem OLE-DB-Provider für InterBase haben Sie die besten Erfahrungen gemacht? Mit dem (kostenpflichtigen) SIBProvider?<br><br>
      Halten Sie meinen Ansatz überhaupt für sinnvoll? Ich muss definitiv zwei DB-Server unterstützen und möchte die Arbeit für eine eigene Klasse, die abhänging von der DB native Zugriffskomponenten verwendet, vermeiden...<br><br>
      Vielen Dank,<br>
      Christian Storfinge

      Comment


      • #4
        Hallo nochmal,<br><br>
        wenn ich im ConnectionString das zur Datenbank passende Character Set übergebe, funktioniert alles wie gewünscht.<br><br>
        Ich werde dann mal versuchen, durch weitgehenden Verzicht auf Stored Procedures zumindest den Zugriff auf Interbase und MS-SQL in gleichen Code zu packen.<br><br>
        Christia

        Comment


        • #5
          Hallo,

          &gt;Mit dem (kostenpflichtigen) SIBProvider?

          nein, mein Beispiel galt der kostenfreien Schnupperversion. Für den InterBase-Zugriff verwendet ich nur IBX.

          &gt;Halten Sie meinen Ansatz überhaupt für sinnvoll?

          Darauf kann es keine pauschale Antwort geben. Der universelle Ansatz (ein Programm für alle Datenbanken) muss zwangsläufig dem "Prinzip des kleinsten gemeinsamen Nenners" folgen, so dass die spezifischen Vorteile der einzelnen Datenbanken nicht ausgenutzt werden können.

          Zum Beispiel splittet der ADO-Nachfolger ADO.NET die Aufgaben in zwei Bereiche auf: <br>
          1. Datenbankspezifische Zugriffsklassen <br>
          2. Universelles DataSet (DataTable, DataRelation, DataView etc.)<br>
          Die datenbankspezifischen Zugriffsklassen stellen gemeinsame Interfaces zur Verfügung, so dass zur Laufzeit umgeschaltet werden kann, ohne dass am Aufruf selbst etwas geändert werden muss

          Comment

          Working...
          X