Wechsel auf 7.1 - .net SQL-Abfragen jetzt langsam

[andreaspr@aon.at]

Du könntest mit Trim() die Blanks abschneiden. Entweder im SQL oder du machst das in einer View.

[BenderD]

... im SQL oder View bringt wohl nix, da der Treiber die Blanks dann wohl wieder dranhängt. Aber C##, C++ und VB. das C# für Arme und Kranke, haben eine Trim() Methode von String und die sollte es tun.

D*B

[andreaspr@aon.at]

... im SQL oder View bringt wohl nix, da der Treiber die Blanks dann wohl wieder dranhängt.

auch getestet?
Woher will der Treiber wissen ob da Blanks drangehängt gehören, wenn ich die Werte mit einer Funktion ändere?!?

[BenderD]

... weil er sich die Feldlänge aus den Metadaten holen. Im SQL könnte da allenfalls ein cast nach varchar funzen.

[andreaspr@aon.at]

... was noch nicht die Frage beantwortet ob die Aussage auch getestet wurde!
Wenn irgendein Treiber oder was auch immer glaubt wissen zu können wie lang das Ergebnis einer Funktion ist, halte ich das für Glaskugellesen!

[BenderD]

... werfe mal einen Blick in die SQL Reference, bevor Du hier starke Sprüche los lässt.
Stichwort create function, falls Du das ohne Hinweis nicht findest!

[andreaspr@aon.at]

Auch ich lerne gerne dazu, also bitte ich um den Hinweis wo steht, dass wenn ich trim() verwende, irgendwo zu sehen ist, wie groß das Ergebnis VIELLEICHT sein "KÖNNTE".
Und dann noch den Hinweis, dass der Treiber auch wirklich so arbeitet!
Wenn das alles schon so klar belegt werden kann ... ja, dann braucht man es wirklich nicht probieren. Ansonsten schadet ein Test nicht um es eindeutig heraus zu finden oder wo liegt da jetzt das Problem?!?

[BenderD]

... bei abgeleiteten Feldern wird nach implizitem Regelwerk ein Typ festgelegt (ansehen kann man sich den, wenn man ein create table as (select...) macht). Das ist unasuweichlich, weil SQL streng Typgebunden ist. Sich auf implizite Regelwerke zu verlassen, ist immer schlecht, falls die nicht klar dokumentiert sind, könnten die sich ändern; besser und einfacher ist, bei erzeugten Feldern den Typ durch ein CAST zu erzwingen.

Die Auffüllerei mit Blanks ist ein Nebeneffekt von Feldern fester Länge, VARCHAR hat das Problem nicht.
Also: cast nach varchar nach TRIM.

Zum Ausprobieren: das kann nicht Sinn eines Forums sein, anderer Leute Probleme durch Ausprobieren zu lösen - ich jedenfalls treibe den Aufwand nicht, Umgebungen zu installieren und zu schauen, ob ich das Problem und/oder einen Lösungsweg verifizieren kann - wem das nicht passt, der braucht meine Postings nicht zu lesen, geschweige denn befolgen!

D*B

[andreaspr@aon.at]

wem das nicht passt, der braucht meine Postings nicht zu lesen, geschweige denn befolgen!

Werden wir uns merken

[andreaspr@aon.at]

... bei abgeleiteten Feldern wird nach implizitem Regelwerk ein Typ festgelegt (ansehen kann man sich den, wenn man ein create table as (select...) macht). Das ist unasuweichlich, weil SQL streng Typgebunden ist. Sich auf implizite Regelwerke zu verlassen, ist immer schlecht, falls die nicht klar dokumentiert sind, könnten die sich ändern; besser und einfacher ist, bei erzeugten Feldern den Typ durch ein CAST zu erzwingen.

Die Auffüllerei mit Blanks ist ein Nebeneffekt von Feldern fester Länge, VARCHAR hat das Problem nicht.
Also: cast nach varchar nach TRIM.

ein Create Table as (Select Trim() ... erstellt mir ein VARCHAR Feld ... also

[Fuerchau]

Zur ODBC-Definition gehört ein Set an Metadaten-Abfragen, die es übrigens auch im embedded SQL gibt.
Describe Table, Describe Statement.
Genauso gibt es im ODBC einen SQLInfo-Funktion die mir Typ und Ausprägung liefert.
Für jede SQL-Funktion sind die Parameter und Ergebnisse eben auch definiert, so ist das Ergebnis eines Trim() immer halt VARCHAR bzw. nun auch NVARCHAR bei Unicode.

Ein OLEDB/ODBC/.NET-Treiber kann nur mit den Metadaten des Systems arbeiten.
Selbständig werden da keine Daten verändert. Wenn also ein Typ CHAR(NN) geliefert wird, hat bei mir der Treiber noch nie die Blanks am Ende entfernt.

Mache ich nun einen Cast eines Char(nn) in Varchar(nn) werden Blanks auch noch nicht entfernt, da diese ja Bestandteil der Information sind. Erst ein Trim() verändern nun mal den Inhalt und liefert VARCHAR als Ergebnis, wobei die definierte Länge vom maximal Möglichen abhängt und einen Cast in VARCHAR nicht mehr erforderlich macht.

Welche Funktionen so für die Metadaten zur Verfügung stehen (bzw. als Mindestanforderungen vorhanden sein müssen) kann man in den ODBC-Spezifikationen oder z.B. im CLI-Handbuch (C-Funktionen) nachlesen. Zudem gibt es zusätzlich noch die diversen SYSxxx-Tabellen in denen man auch so einiges finden kann.