Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » SQL Anywhere 11 - Änderungen und Upgrades » Neue Funktionen in Version 11.0.0 » SQL Anywhere » Neue Funktionen in SQL Anywhere

 

Programmierschnittstellen

Die folgende Liste enthält die Erweiterungen der in SQL Anywhere Version 11.0.0 eingeführten Programmierschnittstellen.

  • Neue SQL Anywhere C-API   Die SQL Anywhere C-Anwendungs-Programmierschnittstelle (API, Application Programming Interface) vereinfacht die Erstellung von C- und C++-Wrapper-Treibern für mehrere interpretierte Programmiersprachen, einschließlich PHP, Perl, Python und Ruby. Die SQL Anywhere C-API setzt auf der DBLIB-Bibliothek auf und wurde mit Embedded SQL realisiert.

    Auch wenn sie kein Ersatz für DBLIB ist, vereinfacht die SQL Anywhere C-API die Erstellung von Anwendungen mit C und C++. Sie benötigen keine umfassenden Kenntnisse von Embedded SQL, um die SQL Anywhere C-API zu verwenden. Weitere Hinweise finden Sie unter SQL Anywhere C-API-Referenz.

  • Neue Python-Datenbank-API (sqlanydb)   Die neue Python-Datenbank-API bietet Zugriff auf SQL Anywhere-Datenbanken über Skripten, die in Python geschrieben sind. Das sqlanydb-Modul implementiert mit Erweiterungen die Python-Datenbank-API-Spezifikation, Version 2.0. Weitere Hinweise finden Sie unter SQL Anywhere Python-Datenbankunterstützung.

  • Externe Umgebungen   SQL Anywhere bietet nun Unterstützung für sechs externe Laufzeitumgebungen: Java, Perl, PHP, CLR, Embedded SQL und ODBC. SQL Anywhere besaß die Fähigkeit, kompilierte native Funktionen, die in C oder C++ geschrieben waren, aufzurufen. Wenn diese Prozeduren vom Server ausgeführt wurden, wurde die dynamische Verknüpfungsbibliothek (DLL) oder das gemeinsam genutzte Objekt immer vom Datenbankserver geladen und die Aufrufe der nativen Funktion wurden immer vom Datenbankserver durchgeführt. Dadurch bestand das Risiko, dass der Datenbankserver abstürzte, wenn die native Funktion einen Fehler verursachte. Durch die Ausführung kompilierter nativer Funktionen außerhalb des Datenbankservers in einer externen Umgebung wird dieses Risiko nun vermieden. Weitere Hinweise finden Sie unter Unterstützung für externe Umgebungen in SQL Anywhere.

    Zur Nutzung dieser neuen Funktion ist ein Datenbank-Upgrade erforderlich. Weitere Hinweise finden Sie unter Upgrade von SQL Anywhere.

  • Unterstützung der externen PHP-Umgebung   SQL Anywhere 11.0.0 verfügt über eine Reihe integrierter Binärdateien für verschiedene PHP-Versionen, einschließlich 5.1.1 bis 5.1.6 und 5.2.0 bis 5.2.6. Wenn eine dieser Versionen auf Ihrem Serversystem installiert ist, sollten Sie die integrierten SQL Anywhere-Binärdateien verwenden, anstatt die externe PHP-Umgebung selbst zu erstellen. Beachten Sie, dass für Linux und Solaris sowohl 32-Bit- als auch 64-Bit-Versionen dieser Binärdateien bereitgestellt werden. Für Windows und andere Betriebssysteme werden nur 32-Bit-Versionen bereitgestellt.

    Wenn Sie eine andere, oben nicht genannte PHP-Version verwenden, müssen Sie die Software selbst erstellen. Sie können Ihre PHP-Version auch durch eine andere Version ersetzen, die zu einer in SQL Anywhere vorkompilierten Version passt. Weitere Hinweise zum Erstellen des PHP-Moduls in SQL Anywhere finden Sie unter SQL Anywhere PHP-API.

  • Unterstützung der externen Perl-Umgebung   Vor der Verwendung der externen Perl-Umgebung muss unbedingt die Version des Perl DBD-Treibers in SQL Anywhere aktualisiert werden. Ohne die Aktualisierung des Perl DBD-Treibers ist Perl serverseitig nicht funktionsfähig.

    Im Unterschied zu PHP werden keine integrierten Binärdateien für verschiedene Versionen von Perl bereitgestellt. Der Quellcode für den Perl DBD-Treiber von SQL Anywhere befindet sich unter Installationsverzeichnis\SDK\perl. Weitere Hinweise zum Erstellen des Perl DBD-Treibers von SQL Anywhere finden Sie unter SQL Anywhere Perl DBD::SQLAnywhere DBI-Modul.

  • Webserver-Unterstützung für UTF-8-URLs   Bislang übersetzte der Webserver %-kodierte Daten innerhalb des Anforderungs-URL (oder Daten im Format "application/x-www-form-urlencoded" im Hauptteil der Anforderung) in den Zeichensatz der Datenbank. Nun wird der Inhalt von %-kodierten Daten auf·UTF-8-Sequenzen geprüft und basierend darauf soweit wie möglich in den Zeichensatz der Datenbank konvertiert. Alle kodierten Daten, die nicht im UTF-8-Format sind, werden dekodiert und so behandelt, als wären sie bereits im Zeichensatz der Datenbank.

    Client-HTTPAnwendungen sollten ausschließlich %-kodierte UTF-8-Daten senden. Beachten Sie, dass ASCII-Zeichen in UFT-8 in ihrer ursprünglichen Form dargestellt werden. Ein Leerzeichen wird beispielsweise als %20 kodiert.

  • Neue Client-Callback-API   Zur Unterstützung der neuen Funktionen zum clientseitigen Laden und Entladen von Daten wurde eine neue Client-Callback-API hinzugefügt. Weitere Hinweise zu Embedded SQL finden Sie unter DB_CALLBACK_VALIDATE_FILE_TRANSFER in db_register_a_callback-Funktion. Weitere Hinweise zu ODBC finden Sie unter SA_REGISTER_VALIDATE_FILE_TRANSFER_CALLBACK in SQL Anywhere-Verbindungsattribute.

  • SQL_ATTR_CONNECTION_DEAD erkennt nun sofort ungültige Verbindungen   Bei der Verwendung des ODBC-Aufrufs SQLGetConnectAttr zum Abrufen des Attributs SQL_ATTR_CONNECTION_DEAD wird nun der Wert SQL_CD_TRUE zurückgegeben, wenn die Verbindung unterbrochen wurde, auch wenn seit der Unterbrechung der Verbindung keine Anforderung an den Server gesendet wurde. Es wird ermittelt, ob die Verbindung unterbrochen wurde, ohne eine Anforderung an den Server zu senden. Die Unterbrechung der Verbindung wird innerhalb weniger Sekunden erkannt. Die Verbindung kann aus mehreren Gründen unterbrochen werden, z.B. aufgrund eines Inaktivitäts-Zeitablaufs. Vor dieser Änderung erhielt SQL_ATTR_CONNECTION_DEAD nur den Wert SQL_CD_TRUE, wenn die Verbindung getrennt wurde oder wenn der ODBC-Treiber eine Anforderung an den Server gesendet hat (z. B. durch den Aufruf von SQLExecDirect), nachdem die Verbindung unterbrochen wurde. Weitere Hinweise finden Sie unter Verbindungsattribute abrufen.

  • JDBC-Treiber unterstützt nun ResultSet.getBlob().getBinaryStream()   Der JDBC-Treiber von iAnywhere unterstützt derzeit die Methode ResultSet.getBlob(). Diese Methode ist in der JDBC-Spezifikation jedoch optional. Die optionale Methode ResultSet.getBlob().getBinaryStream() wird nun ebenfalls unterstützt. Weitere Hinweise finden Sie unter iAnywhere JDBC 3.0 API-Unterstützung.

  • Der iAnywhere JDBC-Treiber akzeptiert nun zusätzlich zu jdbc:odbc: auch jdbc:ianywhere: als URL-Header    Wenn Anwendungen bislang den URL-Header jdbc:odbc verwendet haben, konnte davon ausgegangen werden, dass der JDBC-Treibermanager für das Herstellen von Verbindungen mit diesem URL den iAnywhere JDBC-Treiber verwendete. In neueren Versionen der Java VM wird die Sun JDBC-ODBC Bridge als JDBC-Treiber registriert. Da die Sun JDBC-ODBC Bridge auch URLs akzeptiert, die mit jdbc:odbc beginnen, ist die Wahrscheinlichkeit, dass eine Anwendung die Sun JDBC-ODBC Bridge anstelle des iAnywhere JDBC-Treibers erhält, relativ groß. Um sicherzustellen, dass der JDBC-Treibermanager den iAnywhere-Treiber und nicht die Sun JDBC-ODBC Bridge verwendet, sollte die Anwendung stattdessen den URL-Header jdbc:ianywhere verwenden. Weitere Hinweise finden Sie unter Von einer JDBC-Clientanwendung aus verbinden.

  • ODBC-Treibermanager akzeptiert nun driver=iAnywhere Solutions 11 - Oracle   Der Unix ODBC-Treibermanager akzeptiert nun driver=iAnywhere Solutions 11 - Oracle. Er lädt den iAnywhere ODBC-Treiber für Oracle mit Threading, wenn die Anwendung Threading verwendet. Er lädt den Treiber nicht, wenn die Anwendung kein Threading verwendet, da der iAnywhere ODBC-Treiber für Oracle ohne Threading nicht unterstützt wird. Weitere Hinweise finden Sie unter iAnywhere Solutions Oracle-Treiber.

  • ODBC-Treibermanager akzeptiert nun driver=UltraLite 11   Der UNIX ODBC-Treibermanager akzeptiert bereits die Anweisung driver=SQL Anywhere 10 und lädt den SQL Anywhere ODBC-Treiber einwandfrei (entweder mit oder ohne Threading, abhängig von der Anwendung). Der Unix ODBC-Treibermanager akzeptiert nun driver=SQL Anywhere 11 und driver=UltraLite 11. Im Fall des UltraLite-Treibers lädt der Treibermanager nur die Version des UltraLite-ODBC-Treibers mit Threading, da nur die Version mit Threading verfügbar ist.

  • Erweiterungen der TDS-Verbindungen    Der SQL Anywhere-Datenbankserver gestattet nun TDS-Verbindungen mit der Standarddatenbank, selbst wenn der Open Client-Login-Servername nicht mit dem Namen der Standarddatenbank übereinstimmt. Hierbei darf die Verbindungszeichenfolge keine Datenbank starten (d.h. DBF=... ist nicht vorhanden) und auf dem Datenbankserver darf nur eine Datenbank laufen.

  • Einfacheres erneutes Deployment der Startprogramme für die Administrationstools   Das erneute Deployment der Startprogramme für die Datenbanktools (Sybase Central, DBISQL, DBConsole, MobiLink-Monitor) wurde vereinfacht. Registrierungseinträge und eine feste Verzeichnisstruktur für den Speicherort der JAR-Dateien sind nicht mehr erforderlich. Für jede ausführbare Datei muss im gleichen Verzeichnis eine .ini-Datei vorhanden sein (mit demselben Namen wie die EXE-Datei), die Informationen darüber enthält, wie das Tool geladen wird. Weitere Hinweise finden Sie unter Deployment von Tools zur Verwaltung.

  • SQL Anywhere .NET-Datenprovider unterstützt nun die Eintragung verteilter Transaktionen   In .NET Framework 2.0 wurde der neue Namespace System.Transactions eingeführt, der Klassen zum Programmieren transaktionaler Anwendungen enthält. Clientanwendungen können verteilte Transaktionen mit einem oder mehreren Teilnehmern erstellen und an diesen beteiligt sein. Clientanwendungen können mit der Klasse TransactionScope implizit Transaktionen erstellen. Das Verbindungsobjekt kann feststellen, ob eine von TransactionScope erstellte sogenannte Ambient-Transaction vorhanden ist und diese automatisch eintragen. Clientanwendungen können auch mit CommittableTransaction eine festschreibbare Transaktion erstellen und die Methode EnlistTransaction aufrufen, um sie einzutragen.

    Diese Funktion wird vom SQL Anywhere .NET 2.0-Datenprovider unterstützt. Verteilte Transaktionen haben einen erheblichen Performance-Overhead. Es wird empfohlen, für nicht verteilte Transaktionen Datenbanktransaktionen zu verwenden. Weitere Hinweise finden Sie unter Transaktionsverarbeitung.

  • SQL Anywhere NET.-Datenprovider unterstützt nun benannte Parameter   Der SQL Anywhere-Provider unterstützt nun benannte Parameter in SACommand. Wenn der Benutzer alle Parameternamen angibt, ordnet der Provider bei der Ausführung des Befehls Parameterwerte zu. Bei der Verwendung benannter Parameter muss die Reihenfolge der Parameter nicht mit der Reihenfolge der Hostvariablen übereinstimmen.
    SACommand cmd = new SACommand( 
        "UPDATE MyTable SET name = :name WHERE id = :id", conn );
    
    SAParameter p1 = new SAParameter( 
        "id", SADbType.Integer );
    p1.Direction = ParameterDirection.Input;
    p1.Value = 1;
    cmd.Parameters.Add( p1 );
    
    SAParameter p2 = new SAParameter( 
        "name", SADbType.Char, 40 );
    p2.Direction = ParameterDirection.Input;
    p2.Value = "asdasd";
    cmd.Parameters.Add( p2 );
    
    cmd.ExecuteNonQuery();

  • Erweiterungen der Webdienste   Den Webdiensten wurden in dieser Version folgende Erweiterungen hinzugefügt:

    • Erweiterung der Webclient-Dienstprozeduren vom Typ HTTP:POST für einen benutzerdefinierten Hauptteil    Die TYPE-Klausel der Anweisungen CREATE PROCEDURE und CREATE FUNCTION wurde so erweitert, dass sie nun die Spezifikation eines Mime-Typs erlaubt. Weitere Hinweise finden Sie unter CREATE FUNCTION-Anweisung (Webdienste) oder CREATE PROCEDURE-Anweisung (Webdienste).

    • Erweiterung der Webdienst-Clientprozeduren zur Unterstützung der Methoden PUT, DELETE und HEAD HTTP    Webdienst-Clientprozeduren und -funktionen unterstützen nun die Methoden PUT, DELETE und HEAD HTTP. Die TYPE-Klausel der Anweisungen CREATE PROCEDURE und CREATE FUNCTION wurde erweitert und unterstützt nun diese Methoden. Ähnlich der POST-Methode erfordert PUT eine Content-Type-Erweiterung innerhalb der TYPE-Klausel. Nur ein nicht ersetzbarer Parameter ist zulässig. Weitere Hinweise finden Sie unter CREATE SERVICE-Anweisung, CREATE FUNCTION-Anweisung (Webdienste) und CREATE PROCEDURE-Anweisung (Webdienste).

    • Systemprozeduren sa_http_php_page und sa_http_php_page_interpreted    Die neuen Webdienst-Systemprozeduren sa_http_php_page und sa_http_php_page_interpreted geben das Ergebnis eines Durchlaufs eines PHP-Skripts durch einen PHP-Interpreter zurück. Weitere Hinweise finden Sie unter sa_http_php_page-Systemprozedur und sa_http_php_page_interpreted-Systemprozedur.

    • HTTP_BODY-Systemfunktion   Die neue Webdienst-Funktion HTTP_BODY wurde hinzugefügt. Die Funktion HTTP_BODY gibt den Hauptteil der HTTP-Anforderung in Binärform zurück. Weitere Hinweise finden Sie unter HTTP_BODY-Funktion [HTTP].

    • WSDLC-Unterstützung zum Erzeugen von SOAP-Prozeduren des Webdienstclients   Zusätzlich zum Erzeugen von clientseitigen QAnywhere-SOAP-Schnittstellen für C# und JAVA unterstützt WSDLC nun auch die Erstellung von SQL SOAP-Clientprozeduren (Webdienst) für SQL Anywhere. WSDLC liest einen WSDL1.1-kompatiblen URL oder eine Datei und erzeugt Prozeduren (oder Funktionen) mit geeigneten Parametern und Klauseln, die in der WSDL aufgelisteten SOAP-Vorgängen zugeordnet sind. Die erzeugten SQL-Anweisungen werden in eine SQL-Datei geschrieben. Weitere Hinweise finden Sie unter Den iAnywhere WSDL-Compiler verwenden.

    • HTTP SOAP-Dienste, die mit einer FORMAT-Klausel definiert wurden, können mit EXPLICIT OFF oder ON genauer qualifiziert werden    Bei der Erstellung eines HTTP SOAP-Dienstes ist der Standardwert der FORMAT-Klausel EXPLICIT ON. Das bedeutet, dass die von einem DISH-Dienst generierte WSDL für jede in einer Ergebnismenge zurückgegebene Spalte explizite Namen und Datentypen angibt. Somit können SOAP-Client-Toolkits automatisch clientseitige Objekte und Schnittstellen generieren, die die Ergebnismenge repräsentieren und den Zugriff des Systems auf die Spaltenwerte ermöglichen. Bevor diese Funktion verfügbar war, konnte auf Spaltenwerte nur in Form von abstrakten XML-Datenelementen zugegriffen werden. Dieses Verhalten ist immer noch verfügbar, wenn EXPLICIT OFF angegeben wird.

      Weitere Hinweise zum Definieren eines EXPLICIT-Antwortobjekts oder des generischen SimpleDataset finden Sie unter CREATE SERVICE-Anweisung und Praktische Einführung: Datentypen mit JAX-WS verwenden.

    • Unterstützung der JSON-Webdienste    SQL Anywhere unterstützt nun Webdienste, die JSON-formatierte Antworten zurückgeben. Weitere Hinweise finden Sie unter CREATE SERVICE-Anweisung.

  • Protokollierung von Webdienst-Clients   Der Datenbankserver unterstützt nun die Protokollierung von Webdienst-Clientverbindungen in einer Ausgabedatei. Sie können die Serveroption -zoc angeben oder die Eigenschaften WebClientLogFile und WebClientLogging zusammen mit der Systemprozedur sa_server_option verwenden, um die Protokollierung zu steuern und den Speicherort der Webdienst-Clientprotokolldatei festzulegen. Sie können die Verwendung dieser Funktion mit der Serveroption -sf auch deaktivieren. Weitere Hinweise finden Sie unter: