Re: UNICODE Query's in Access und MSSQL
- From: "Elmar Boye" <ElmarB@xxxxxxx>
- Date: Tue, 26 Apr 2005 10:04:29 +0200
Hallo Alexander,
Alexander Baumgart <al.baumgart@xxxxxx> schrieb ...
> ich habe eine Access DB auf einen SQL Server portiert. Die
> zugrundeliegenden Anwendung, die DB verwendete liefert auch einige
> UNICODE Daten. Mit Access als DB Engine konnte ich dabei auf eine
> Kennzeichnung ala "N'" verzichten. Unter SQL (MSDE) muss ich dieses
> aber nun angeben.
> Gibt es eine UNICODE taugliche Syntax die auf beiden System geht ?
Nein. Das
> Oder sind hier die Jet Engine und der SQL Server wiedereinmal verschieden?
Bei der Jet hat man mit 3.5 (A97) auf 4.0 (A2000++) einen internen
Wechsel vorgenommen und alle ANSI Datentypen als Unicode definiert,
sprich dort ist varchar auch Unicode also nvarchar.
Das N'-Präfix - im übrigen ANSI Syntax - hat meinste man sich da
sparen zu können.
> Wenn ich die MDB Datei auf Access 2003 portiert wuerde das helfen ?
Das hängt von der Jet Version ab und die heisst 4.0 seit Access 200.
Sie befindet sich im Maintenance Modus, und wird nur durch Service Packs
aktualisiert, siehe http://support.microsoft.com/?kbid=239114
> Aus der Anwendung wird per ADO und SQL Cmd zugegriffen.
Solange Du über die Parameters Auflistung arbeitest, erledigt
das der Treiber für Dich.
Für dynamisch erstelltest SQL bietet sich wie bei anderen Datentypen
z. B. DATETIME - an, alle Variablen durch eine Funktion vorverarbeiten
zu lassen. Bei Zeichenketten wegen des allfälligen "''" Problems
ohnehin erforderlich.
> Weiterhin habe ich gelesen das UNICODE generell zur Darstellung 2Byte
> verwendet , man unter Access aber eine Art Komprimierung einstellen
> kann, die wenn keine 2Bytes benoetigt werden eingreift.
Vorausgesetzt Du hast die Unicode Kompression aktiviert.
Das wäre beim CREATE TABLE:
Spalte nvarchar(40) WITH COMP (oder WITH COMPRESSION)
> Sowohl Access als auch MSDE haben meines wissen eine Maximale DBgroesse
> von 2GB was wiederum auch bedeutet das eigenlich in Access viel mehr
> Daten passen wuerden als in MSDE.
Naja, erstens gibts da noch die grossen SQL Server Versionen.
Zweiten hast Du bei der Jet keine ANSI-Datentypen mehr - und
für viele Inhalte reichen die aus und sind dann vorzuziehen.
Drittens wird eine Jet MDB an der Kapazitätsgrenze betrieben
schnell instabil...
> Weiterhin habe ich gelesen das man bei der Sortierung von UNICODE
> Felder aufpassen muss, da sonst eben ABC = abc ist und das keine Index
> genutzt werden, was zu erheblichen Performanceneinbussen fuehren kann.
Bei der Jet gilt das immer, da Du keinen Einfluss auf die Sortier-
und Vergleichsreihenfolge hast, und dort ohne Berücksichtigung der
Gross-/Kleinschreibung gearbeitet wird. Alles andere erfordert
programmatischen Aufwand (wie VBA StrComp).
Beim SQL Server hängt es von der COLLATE Angabe der Spalte ab.
Und ein Index wird verwendet, wenn die Vergleichsreihenfolge
stimmt und nicht etwas wie LOWER(Spalte) = 'abc' verwendet wird,
Wobei da LOWER/UPPER schon mal Ansi-Funktionen sind und nicht
Unicode tauglich. ein vergleich mit anderer Vergleichsreihenfolge
sollte COLLATE verwenden. Als Beispiel:
CREATE TABLE Tabelle(
Spalte_CI_AS nvarchar(40) COLLATE Latin1_General_CI_AS,
Spalte_CS_AS nvarchar(40) COLLATE Latin1_General_CS_AS,
Spalte_CI_AI nvarchar(40) COLLATE Latin1_General_CI_AI)
INSERT INTO Tabelle VALUES (N'abc', N'abc', N'abc')
INSERT INTO Tabelle VALUES (N'ABC', N'ABC', N'ABC')
INSERT INTO Tabelle VALUES (N'ábc', N'ábc', N'ábc')
GO
SELECT * FROM Tabelle WHERE Spalte_CI_AS = 'abc'
SELECT * FROM Tabelle WHERE Spalte_CS_AS = 'abc'
SELECT * FROM Tabelle WHERE Spalte_CI_AI = 'abc'
SELECT * FROM Tabelle
WHERE Spalte_CI_AS = 'abc' COLLATE Latin1_General_CS_AS
GO
Gruss
Elmar
.
- Prev by Date: Re: Liste an Procedure übergeben
- Next by Date: SQL Server Problem...
- Previous by thread: Zugriff auf SQL-Tabellen
- Next by thread: SQL Server Problem...
- Index(es):
Relevant Pages
|
