Wechsel auf 7.1 - .net SQL-Abfragen jetzt langsam

[Oli001]

Hallo, das ist ein initialer select der 120000 Sätze lädt. Vor dem Wechsel 8 sek. Jetzt fast 2 min. Mach ich den select über Java, hab ich das Phänomen nicht. Dann sind es wie vorher mit odbc nur 8 sek...
Bin Softwareentwickler und hab relativ wenig Ahnung von der AS400... Werde das morgen mal weiterleiten und hoffe, dass das dann klappt...

[Oli001]

Guten Morgen,
ich möchte das Problem nochmal etwas konkretisieren, mein Quellcode sieht so aus:

string sql ="select * from bibl.table";
OleDbDataReader dr=new OleDbCommand(sql, AS400Connection.getConnection()).ExecuteReader();
//Diese Anweisung wird innerhalb von 1 sek ausgeführt!
int c=0;
while(dr.Read())
c++; <-- Wenn ich hier nur den Counter laufen lasse braucht er 2 min bis er durch ist für 120.000 Sätze!

Wie gesagt seltsam ist halt, dass das bei Tabellen auftritt, die ein Journal haben. Wenn ich eine Tabelle ohne Journal nehme, und durch Schleife rumpeln lasse ist das in 2 sek. erledigt. Und das bei 16.000.000 Sätzen!

Grüße Oli

[BenderD]

.. was verwendet ihr denn hier für ein isolation (commit) level?

[Oli001]

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]

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?!?