View Full Version : Wechsel auf 7.1 - .net SQL-Abfragen jetzt langsam
Hallo,
erstmal vielen Dank für eure Hilfe!
Ich habe nun eine Lösung gefunden. Ich verwende nicht mehr den OleDb-Treiber sondern den IBM.Data.DB2.iSeries. Damit geht es gefühlt nochmal schneller als vorher...
Nun hab ich allerdings eine kleine Problemchen: Wenn ich mit dr.GetString(0) ein Feld aus der DB hole, dann ist das Ergebnis mit Blanks gefüllt (Soviele Blanks bis die Feldgröße erreicht ist). z.B. 'oli001 ' bei einem char(10). Kann man das irgendwie umgehen? Der OleDb hat hier nur 'oli001' geliefert.
Grüße Oli
andreaspr@aon.at
19-11-14, 12:32
Du könntest mit Trim() die Blanks abschneiden. Entweder im SQL oder du machst das in einer View.
... 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
19-11-14, 14:33
... 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?!?
... weil er sich die Feldlänge aus den Metadaten holen. Im SQL könnte da allenfalls ein cast nach varchar funzen.
andreaspr@aon.at
19-11-14, 21:57
... 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!
... 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
20-11-14, 08:54
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?!?
... 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
20-11-14, 10:55
wem das nicht passt, der braucht meine Postings nicht zu lesen, geschweige denn befolgen!
Werden wir uns merken ;)