Programmierschnittstellen

Erweiterungen der Performance von Webdiensten HTTP-Dienste unterstützen nun automatisches Verbindungspooling, um die Wirkung der Planzwischenspeicherung zu maximieren und die Performance zu steigern. Siehe Webdienstanwendungen auf einem HTTP-Webserver entwickeln.

Unterstützung für benutzerdefinierte ODBC-Treibernamen Um die Installation und Registrierung mehrerer unabhängiger Kopien des ODBC-Treibers von SQL Anywhere auf einem Client zu vereinfachen, können Sie dem ODBC-Treiber nun einen benutzerdefinierten Namen zuweisen. Siehe ODBC-Treiber konfigurieren.

Reiner ANSI-ODBC-Treiber für Unix Die Versionen von ODBC-Treibermanagern für Unix, die SQLWCHAR als 32-Bit-Mengen (UTF-32) definieren, können nicht mit dem SQL Anywhere-ODBC-Treiber verwendet werden, der breite Aufrufe unterstützt, da dieser Treiber für 16-Bit-SQLWCHAR erstellt wurde. Für solche Fälle wird eine reine ANSI-Version des SQL Anywhere-ODBC-Treibers zur Verfügung gestellt. Diese Version des·ODBC-Treibers unterstützt keine Schnittstellen für breite Aufrufe (z.B. SQLConnectW). Siehe UTF-32-ODBC-Treibermanager unter Unix.

DBTools: Das no_reload_status-Bitfeld wurde der an_unload_db-Struktur hinzugefügt Die Struktur an_unload_db umfasst nun das neue Bitfeld no_reload_status. Sie können no_reload_status verwenden, um Fortschrittsmeldungen für Tabellen und Indizes beim Neuladen zu unterdrücken. Siehe an_unload_db-Struktur.

Neuer SQL Anywhere TYPE-2 JDBC-Treiber JDBC-Anwendungen steht bei der Verbindung mit SQL Anywhere ein neuer TYPE-2 JDBC-Treiber zur Verfügung. Anders als der iAnywhere JDBC-Treiber, der auf ODBC aufgesetzt wird und für die Verbindung mit verschiedenen Servern über ODBC verwendet werden kann, wird der JDBC-Treiber ausschließlich mit SQL Anywhere verbunden. Er erfordert weder die Installation noch die Registrierung des SQL Anywhere ODBC-Treibers.

Der SQL Anywhere JDBC-Treiber wird mit einem JDBC 3.0-Treiber und einem JDBC 4.0-Treiber ausgeliefert.

Hinweis

Anwendern des iAnywhere JDBC-Treibers wird empfohlen, auf den neuen SQL Anywhere JDBC-Treiber umzusteigen.

Der JDBC 4.0 Treiber lädt und registriert sich automatisch selbst.

Um Version 3.0 des SQL Anywhere JDBC-Treibers verwenden zu können, müssen Sie die Klasse sybase.jdbc.sqlanywhere.IDriver laden, die die java.sql.Driver-Schnittstelle implementiert und den SQL Anywhere JDBC-Treiber beim JDBC-Treibermanager registriert. Anschließend können Verbindungen mit dem SQL Anywhere JDBC-Treiber über die folgende URL hergestellt werden: jdbc:sqlanywhere:Verbindungszeichenfolgen_Parameter. Die Verbindungszeichenfolgen_Parameter sind Standardverbindungsparameter, die für die Verbindung mit SQL Anywhere erforderlich sind. Beachten Sie, dass bei Verwendung des SQL Anywhere JDBC-Treibers die Angaben DRIVER= oder DSN= für die Verbindungszeichenfolgen_Parameter nicht mehr erforderlich sind. Siehe JDBC-Unterstützung.

Neue Unterstützung für Klassenmethoden von JDBC-Anweisungen In früheren Versionen unterstützten JDBC-Treiber nur die addBatch- und executeBatch-Methoden der PreparedStatement-Klasse. Die JDBC-Treiber unterstützen nun außerdem die Methoden addBatch, clearBatch und executeBatch der Statement-Klasse. Da die JDBC-Spezifikation im Hinblick auf das Verhalten der executeBatch-Methode der Klasse Statement unklar ist, sollten die folgenden Hinweise in Betracht gezogen werden, wenn diese Methode mit dem SQL Anywhere-JDBC-Treiber verwendet wird:

Die Verarbeitung des Batches wird sofort angehalten, wenn eine SQL-Ausnahmebedingung oder eine Ergebnismenge erkannt wird. Beim Anhalten der Batchverarbeitung wird von der executeBatch-Methode ein BatchUpdateException-Objekt ausgegeben. Mit dem Aufruf der getUpdateCounts-Methode für das BatchUpdateException-Objekt wird ein Ganzzahl-Array von Zeilenanzahlen zurückgegeben, in dem die Menge der Anzahlen vor dem Batchfehler eine gültige nicht negative Aktualisierungsanzahl enthält, während alle Anzahlen ab dem Batchfehler den Wert -1 enthalten. Das Umwandeln des BatchUpdateCount-Objekts in ein SQLException-Objekt liefert zusätzliche Einzelheiten dazu, warum die Batchverarbeitung angehalten wurde.
Der Batchinhalt wird nur gelöscht, wenn die clearBatch-Methode explizit aufgerufen wurde. Daher wird bei wiederholtem Aufrufen der executeBatch-Methode der Batch immer wieder neu ausgeführt. Außerdem wird beim Aufrufen von execute( sql_query ) oder executeQuery( sql_query ) zwar die angegebene SQL-Abfrage korrekt ausgeführt, aber der Batchinhalt wird nicht gelöscht. Wenn Sie also die executeBatch-Methode aufrufen, gefolgt von execute(sql_query) und gefolgt von einem erneuten Aufruf der executeBatch-Methode, werden die im Batch zusammengefassten Anweisungen ausgeführt, anschließend wird die angegebene SQL-Abfrage ausgeführt und schließlich werden die im Batch zusammengefassten Anweisungen erneut ausgeführt.

Siehe JDBC-Unterstützung.

Die RESUME-Anweisung gibt die Zeilenanzahl oder den geschätzten Wert für die Zeilenanzahl zurück. Die RESUME-Anweisung gibt die Zeilenanzahl in der Ergebnismenge oder die geschätzte Zeilenanzahl für die nächste Ergebnismenge in einem Prozeduraufruf zurück. In früheren Versionen war dieser Vorgang mit der RESUME-Anweisung nicht möglich. Um die Zeilenanzahl mit RESUME zu ermitteln, müssen sowohl die Clientanwendung als auch der Datenbankserver SQL Anywhere 12 verwenden.

Diese Änderung hat Auswirkungen auf die folgenden Client-APIs:

API	Funktionsaufruf oder Anweisung	Rückgabe der Zeilenanzahl durch
Embedded SQL	RESUME-Anweisung	SQLCOUNT-Feld
ODBC	SQLMoreResults-Funktion	SQLRowCount-Funktion
OLE DB	IMultipleResults::GetResult-Methode	pcRowsAffected-Ausgabeparameter
PHP	sasql_next_result-Funktion	sasql_num_rows-Funktion
PHP	sasql_stmt_next_result-Funktion	sasql_stmt_num_rows-Funktion
SQL Anywhere C-API	sqlany_get_next_result-Funktion	sqlany_num_rows-Funktion
SQL Anywhere Ruby-API	sqlany_get_next_result-Funktion	sqlany_num_rows-Funktion
SQL Anywhere Python-API	nextset-Methode	rowcount-Attribut

PHP $_SERVER-Variable enthält jetzt alle von CGI/1.1 benötigten Variablen Die $_SERVER-Variable in PHP enthält nun alle Variablen, die von CGI/1.1 bei der Ausführung einer HTTP-Anforderung benötigt werden. Siehe Die externe PHP-Umgebung.

Weitere Hinweise zu den Variablen, die von CGI/1.1 benötigt werden, finden Sie im Abschnitt 4 von RFC3875: [external link] http://www.ietf.org/rfc/rfc3875

Genaue Kontrolle über Python-Datentypzuordnung wurde in sqlanydb hinzugefügt Um zu steuern, wie Datenbanktypen beim Abrufen von Ergebnissen vom Datenbankserver Python-Objekten zugeordnet werden, können Sie Konvertierungs-Callbacks registrieren. Siehe Datenbanktypkonvertierung.

Neue DBLib fill_sqlda_ex-Funktion Die fill_sqlda_ex-Funktion bietet über fill_sqlda eine zusätzliche Funktionalität. Insbesondere kann ein Parameter bereitgestellt werden, um die DT_LONGVARCHAR-, DT_LONGNVARCHAR- und DT_LONGBINARY-Datentypen beim Füllen des Deskriptors zu bewahren. Siehe fill_sqlda_ex-Funktion.

Auswahl der dialogfreien Installation ist nun möglich Unter Windows können SQL Anywhere-Komponenten oder -Funktionen für die Installation von der Befehlszeile ausgewählt oder weggelassen werden. Geben Sie z.B. AT32=1 für die Auswahl der 32-Bit-Administrationstools an. Siehe Dialogfreie Installation für das Deployment.

TDS unterstützt nun die Gesamtstellenzahl von 6 Ziffern für time- und datetime-Daten Anwendungen, die unter Verwendung von jConnect 7 und höher oder Open Client 15.5 und höher eine Verbindung zu SQL Anywhere herstellen, können nun bei der Abfrage von time- oder datetime-Daten eine Gesamtstellenzahl von 6 Ziffern abrufen.