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.1

 

Verhaltensänderungen von SQL Anywhere und veraltete Funktionen

Im Folgenden finden Sie eine nach Kategorien sortierte Liste der Änderungen für SQL Anywhere-Datenbanken und -Datenbankserver in Version 11.0.1.

Verhaltensänderungen
  • Volltextsuche   Die folgenden Verhaltensänderungen wurden für die Volltextsuche vorgenommen:

    • Ab nun unterliegen Operatoren bestimmten Vorrangregeln.   In früheren Versionen unterlagen Operatoren in einer Abfragezeichenfolge keinen Vorrangregeln. Der Vorrang der Operatoren ist jetzt wie folgt geregelt:

      • NEAR- und FUZZY-Operatoren
      • AND NOT-Operator
      • AND-Operator
      • OR-Operator

      Weitere Hinweise finden Sie unter Operatorvorrang in einer CONTAINS-Suchbedingung.

    • Argumente für die NEAR-Klausel müssen Begriffe oder Präfixbegriffe sein.   Wenn Sie eine Nachbarschaftssuche durchführen, müssen die Argumente für die NEAR-Klausel Begriffe oder Präfixbegriffe sein. Weitere Hinweise finden Sie unter CONTAINS-Suchbedingung und Nachbarschaftssuche.

    • Verwendung von Bindestrich und AND NOT-Klausel   Innerhalb eines Satzes wird ein Bindestrich als Begriffsegmentierer und nicht als Sonderzeichen behandelt. Außerhalb eines Satzes ist die Bindestrichbehandlung von der Syntax um den Bindestrich herum abhängig. Weitere Hinweise finden Sie unter Zulässige Syntax für den Bindestrich (-) und Den AND NOT-Operator in der Volltextsuche verwenden.

    • Präfixsuche mit Sternchen   Wenn Sie eine Präfixsuche durchführen, hängen Sie das Sternchen an den Begriff an und setzen Sie direkt dahinter ein Leerzeichen, das Ende der Textabfragezeichenfolge oder eines der zugelassenen Sonderzeichen. Weitere Hinweise finden Sie unter Zulässige Syntax für den Sternchen-Platzhalter (*) und Präfixsuche.

    • Der Versuch, einen mehrfach vorhandenen Textindex zu erstellen, führt nun zu einem Fehler.   Es ist nicht mehr möglich, mehrfach vorhandene Textindizes zu erstellen. Ein Textindex ist mehrfach vorhanden, wenn die folgenden Einstellungen mit denen eines bereits existierenden Textindex übereinstimmen:

      • Die referenzierte Basistabelle.

      • Die Spalten, die mit einem Index versehen werden sollen (Reihenfolge spielt keine Rolle).

      • Die Einstellungen für das verwendete Konfigurationsobjekt (Begriffsegmentierer (TERM BREAKER), Begriffmindestlänge (MINIMUM TERM LENGTH), Begriffhöchstlänge (MAXIMUM TERM LENGTH), Stoppliste (STOPLIST), Kollatierungsinformationen).

      Mehrfach vorhandene Textindizes, die mit einer früheren Version als SQL Anywhere 11.0.1 erstellt wurden, können in der Datenbank erhalten bleiben und verursachen keine Fehler, wenn sie mit einem Datenbankserver der Version 11.0.1 gestartet werden. Das erneute Laden einer Datenbank mit mehrfach vorhandenen Textindizes in Version 11.0.1 oder später führt jedoch zu einem Fehler.

      Um mehrfach vorhandene Textindizes in einer vorhandenen Datenbank zu ermitteln, führen Sie die folgende Abfrage aus:

      SELECT LIST( i.index_name )
      FROM SYS.SYSIDX i 
          JOIN SYS.SYSTEXTIDX t ON i.object_id = t.index_id AND t.sequence = 1
          JOIN SYS.SYSTEXTCONFIG F ON F.object_id = t.text_config
          JOIN ( 
      	SELECT table_id, index_id, LIST( column_id, ', ' ORDER BY column_id ) col_id
      	FROM SYS.SYSIDXCOL
      	GROUP BY table_id, index_id) x 
      	ON x.table_id = i.table_id AND x.index_id = i.index_id
      WHERE i.index_category=4
      GROUP BY i.table_id, f.term_breaker, f.min_term_length, f.max_term_length, 
          f.collation, ISNULL( f.char_stoplist, '-' ), 
          ISNULL( f.nchar_stoplist, '-' ), x.col_id
      HAVING count(*) > 1

      Diese Abfrage funktioniert nur, wenn die Zeichenfolgen für STOPLIST exakt übereinstimmen oder NO STOPLIST angegeben ist. Zum Beispiel sieht diese Abfrage die Stopplisten 'a b c' und 'a - b c' nicht als dieselben an, die jedoch bei einer Suche nach Duplikaten während der Textindexerstellung als übereinstimmend gelten würden.

  • Reguläre Ausdrücke   Für die Suchbedingungen SIMILAR TO und REGEXP sowie für die Funktion REGEXP_SUBSTR wurde das Verhalten geändert. Dadurch bleibt SIMILAR TO weiterhin mit dem ANSI/SQL-Standard konsistent, während das Verhalten von REGEXP und REGEXP_SUBSTR jetzt konsistent mit Perl ist.

    • Datenbankkollatierungen und Suche nach Übereinstimmungen   In Vorgängerversionen verwendeten REGEXP und REGEXP_SUBSTR die Kollationsäquivalenz und Sortierreihenfolge, um zu erkennen, ob ein Literal- oder Zeichenklassenbereich im Muster mit der entsprechenden Zeichenfolge übereinstimmt. Jetzt greifen REGEXP und REGEXP_SUBSTR auf binäre Vergleiche von Codepunktwerten für die Suche nach Übereinstimmungen und die Bereichsauswertung zurück. Die Änderung wurde vorgenommen, um ein mit Perl 5.0 konsistentes Verhalten zu ermöglichen.

      SIMILAR TO verwendet immer noch die Datenbankkollatierung für die Suche nach Übereinstimmungen und zur Bereichsauswertung. Weitere Hinweise finden Sie unter Die Suchbedingungen LIKE, REGEXP und SIMILAR TO.

    • Berücksichtigung der Groß- und Kleinschreibung in Datenbanken und [[:upper:]]- bzw. [[:lower:]]-Teilzeichenklassen   Bisher wurde in Datenbanken, in denen die Groß- und Kleinschreibung nicht berücksichtigt wurde, auch bei den Teilzeichenklassen [[:upper:]] und [[:lower:]] von SIMILAR TO und REGEXP nicht zwischen Groß- und Kleinbuchstaben unterschieden. In der neuen Version berücksichtigt [[:upper:]] nur Großbuchstaben und [[:lower:]] nur Kleinbuchstaben, unabhängig von der Berücksichtigung von Groß- und Kleinschreibung in der Datenbank.

    • Behandlung von Einschaltungszeichen (^), Unterstrich (_) und Prozentzeichen (%) als Metazeichen   In der nachfolgenden Tabelle wird die frühere und die neue Verwendung dieser Zeichen als Metazeichen erklärt:

      Zeichen Früheres Verhalten Neues Verhalten
      _ (Unterstrich) Für SIMILAR TO, REGEXP und REGEXP_SUBSTR diente ein Unterstrich als Metazeichen, das jedes einzelne Zeichen fand.

      Für SIMILAR TO dient ein Unterstrich als Metazeichen, das jedes einzelne Zeichen findet.

      Für REGEXP und REGEXP_SUBSTR dient ein Unterstrich nicht als Metazeichen. Stattdessen wird für REGEXP und REGEXP_SUBSTR ein Punkt (.) verwendet, um jedes einzelne Zeichen zu finden.

      % Für SIMILAR TO, REGEXP und REGEXP_SUBSTR diente ein Prozentzeichen als Metazeichen, das jede Anzahl von beliebigen Zeichen fand.

      Für SIMILAR TO dient ein Prozentzeichen als Metazeichen, das jede Anzahl von beliebigen Zeichen findet.

      Für REGEXP und REGEXP_SUBSTR dient ein Prozentzeichen nicht als Metazeichen. Stattdessen wird für REGEXP und REGEXP_SUBSTR ein Punkt, gefolgt von einem Sternchen (.*) verwendet, um jede Anzahl von beliebigen Zeichen zu finden.

      ^ Für SIMILAR TO, REGEXP und REGEXP_SUBSTR diente ein Einschaltungszeichen innerhalb einer Zeichenklasse als Negations- oder Subtraktionszeichen für alles, was rechts davon stand: Damit wurde also nach allen Zeichen gesucht, die nicht in dieser Menge waren.

      Für SIMILAR TO dient ein Einschaltungszeichen als Negations- oder Subtraktionszeichen für alle Zeichen, die rechts davon stehen. Beispiel: SIMILAR TO [a-d^c] findet a, b, d, aber nicht c.

      Für REGEXP und REGEXP_SUBSTR dient ein Einschaltungszeichen nur als Metazeichen, wenn es an erster Stelle innerhalb einer Zeichenklasse steht: In diesem Fall wird es als Negation der Zeichenklasse interpretiert. Beispiel: REGEXP [^abc] findet jedes einzelne Zeichen, das nicht a, b oder c ist, während REGEXP [a-d^c] a, b, c, d und ^ findet.

  • Für Mac OS X ist das Dienstprogramm dbmodenv nicht mehr erforderlich.   Um in früheren Versionen die grafischen Verwaltungstools mit Mac OS X verwenden zu können, mussten Benutzer in der Datei $HOME/.MacOSX/environment.plist den SQL Anywhere-Binär- und Bibliothekspfad zu PATH und DYLD_LIBRARY_PATH hinzufügen. Hierfür wurde das Dienstprogramm dbmodenv eingesetzt. Da SQL Anywhere nun nicht mehr von den Einstellungen in $HOME/.MacOSX/environment.plist abhängt, ist es nicht mehr notwendig, dbmodenv auszuführen oder sich nach dem Installieren von SQL Anywhere ab- und wieder anzumelden.

  • Neuer Standard bei der Angabe von Nullwerten durch die OUTPUT-Anweisung in dbisqlc   Bei der Verwendung der OUTPUT-Anweisung von dbisqlc gab die Anweisung bisher den Wert (NULL) für Nullwerte zurück. Ab jetzt gibt die Anweisung standardmäßig eine leere Zeichenfolge für Nullwerte zurück. Mit der Option output_nulls können Sie festlegen, wie NULL exportiert wird. Weitere Hinweise finden Sie unter output_nulls-Option [Interactive SQL].

  • Endian-Unterstützung   Nach einem Upgrade müssen Textindizes, die in Versionen vor 11.0.1 auf einem Big-Endian-Computer erstellt wurden, gekürzt und aktualisiert (MANUAL REFRESH- und AUTO REFRESH-Textindizes) oder neu erstellt werden (IMMEDIATE REFRESH-Indizes).

  • Verwaltungstools in Mac OS X   In Mac OS X verwenden die SQL Anywhere-Verwaltungstools nun 64-Bit JDK 1.6. Die Verwaltungstools laufen nur auf Intel Macintosh-Systemen mit 64-Bit-Prozessoren, die von Apple JDK 1.6 (Mac OS X 10.5.2 oder später) unterstützt werden. Beim Deployment der Verwaltungstools für Mac OS X finden Sie die nativen Bibliotheken unter $SQLANY11/System/lib64.v. Weitere Hinweise finden Sie unter Deployment von Verwaltungstools unter Linux, Solaris und Mac OS X.

  • Neue Standardgröße für aufgeteilte Übertragungskodierung für HTTP-Clients   Bisher wurde die aufgeteilte Übertragungskodierung standardmäßig angewendet, wenn die Größe der vom HTTP-Client gesendeten Daten mehr als 2048 Byte betrug (oder wenn der Benutzer CREATE PROCEDURE ... SET 'HTTP(CH=auto)' angab). Die Standardgröße wurde jetzt von 2048 in 8196 Byte geändert. Darüber hinaus wurde der neue Status, 411 Länge erforderlich, zu den Kriterien für die erneute Ausgabe der Anforderung ohne Verwendung der aufgeteilten Übertragungskodierung hinzugefügt. Weitere Hinweise finden Sie unter CREATE PROCEDURE-Anweisung (Webdienste).

Nicht weiterentwickelte und nicht mehr unterstützte Funktionen
  • COMMENT ON EXTERNAL ENVIRONMENT OBJECT Objektname   Die Syntax wurde in COMMENT ON EXTERNAL OBJECT Objektname geändert. Die alte Syntax wird zwar derzeit noch akzeptiert, in einer zukünftigen Version jedoch eventuell nicht mehr unterstützt. Weitere Hinweise finden Sie unter COMMENT-Anweisung.