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. Siehe SQL Anywhere-C-API-Unterstützung.

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 die Python-Datenbank-API-Spezifikation Version 2.0 mit Erweiterungen. Siehe Python-Unterstü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 Shared Object 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. Siehe Unterstützung für externe Umgebungen in SQL Anywhere.

Zur Nutzung dieser neuen Funktion ist ein Datenbank-Upgrade erforderlich. Siehe SQL Anywhere-Server-Ugrades.

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 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-Unterstützung.

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 stellt SQL Anywhere 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 %SQLANY11%\SDK\perl. Weitere Hinweise zum Erstellen des Perl DBD-Treibers von SQL Anywhere finden Sie unter Perl/DBI-Unterstützung.

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 Erweiterte Verbindungsattribute für SQLSetConnectAttr.

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-Timeouts. 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. Siehe 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. Siehe JDBC 4.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. Siehe Verbindungen aus einer JDBC-Clientanwendung.

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. Siehe SQL Anywhere 16 - Oracle-ODBC-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. Beim UltraLite-Treiber 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. Siehe Deployment von Administrationstools.

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 zur Erstellung 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 Ambient-Transaktion 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-Datenprovider unterstützt. Verteilte Transaktionen haben einen erheblichen Performance-Overhead. Es wird empfohlen, für nicht verteilte Transaktionen Datenbanktransaktionen zu verwenden. Siehe 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. Siehe CREATE FUNCTION-Anweisung [Webdienst] 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. Siehe CREATE SERVICE-Anweisung [HTTP-Webdienst], CREATE SERVICE-Anweisung [SOAP-Webdienst], CREATE FUNCTION-Anweisung [Webdienst] 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. Siehe 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. Siehe HTTP_BODY-Funktion [Webdienst].
WSDLC-Unterstützung zum Erzeugen von SOAP-Prozeduren des Webdienstclients WSDLC unterstützt nun auch die Generierung 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.
HTTP SOAP-Dienste, die mit einer FORMAT 'CONCRETE'-Klausel definiert wurden, können mit EXPLICIT OFF bzw. 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 [SOAP-Webdienst] und Praktische Einführung: Verwenden von JAX-WS für den Zugriff auf einen SOAP/DISH-Webdienst.
Unterstützung der JSON-Webdienste SQL Anywhere unterstützt nun Webdienste, die JSON-formatierte Antworten zurückgeben. Siehe CREATE SERVICE-Anweisung [HTTP-Webdienst].

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-Client-Logdatei festzulegen. Sie können die Verwendung dieser Funktion mit der Serveroption -sf auch deaktivieren. Siehe: