Probleme mit dbExpress.NET und grossen Ergebnissmengen

[tomaten]

Hallo. In der Borland Newsgroup für dbExpress kann oder will mir keiner helfen. Ich habe ein Problem mit dbExpress.NET von Delphi 2006 und Oracle. Ich habe eine Abfrage die mir ungefähr 25000 Records als Ergebniss liefert. Mit dbExpress Win32 bekomme ich die ohne Problem. dbExpress.NET hängt sich dabei auf! Ich bekomme eine hohe CPU Last mit der Anwendung und nichts passiert mehr. Dabei habe ich sowohl den originalen Treiber getestet, als auch den von Corelab. Weiss hier jemand näheres darüber? Evtl. ist es ja nur eine Einstellungssache, was ich aber nicht glaube. :(

[tomaten]

Hallo? Hat keiner ausser mir das Problem?

[Bernhard Geyer]

Wenns beim CoreLab-Treiber auch passiert so würde ich doch mal dort das Problem schildern. Die Antwortwahrscheinlichk ist mit sicherheit höher als wenn du es bei Borland einkippen würdest.

[tomaten]

Ja das Gefühl hab ich leider auch! :( Evtl. wissen die zumindest an wem es liegt.

[tomaten]

Formulier ich das irgendwie falsch oder warum bekomme ich von keinem Menschen auf diesem Planeten eine Antwort (ausser hier Quellentipps)? Benutzt keiner ausser mir dbExpress.NET?

[merlin17]

Thomas,

also, ich habe bisher nicht mit dbExpress.net gearbeitet; aber Dein Thread hat mich jedoch neugierig gemacht.

folgendes Szenario:
Oracle 10gR2 auf Win32 (ist aber nebensächlich)
Oracle 9iClient (habe noch 8.1.6.0 auf HP-UX...)
eine BDS2006 mit Upd1
Oracle-Tabelle mit 92.000 DS

Ich habe sowohl für VCL.32 als auch für VCL.net die gleich App gebastelt (nicht migriert/kopiert)

Delphi-Quellcode:

 TForm2 = class(TForm)
    SQLCON: TSQLConnection;
    DataSetProvider1: TDataSetProvider;
    ClientDataSet1: TClientDataSet;
    DataSource1: TDataSource;
    DBGrid1: TDBGrid;
    Button1: TButton;
    SQLQuery1: TSQLQuery;
    Label1: TLabel;

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  c, t1, t2: int64;
begin
  QueryPerformanceFrequency(c);
  QueryPerformanceCounter(t1);
  ClientDataSet1.Active := True;
  QueryPerformanceCounter(t2);
  Label1.Caption := 'active ' +
    IntToStr((t2 - t1) * 1000 div c) + ' ms';
end;

und jetzt kommt es ....
bei vcl.32 dauert es ca. 7 sek, bei vcl.net dauert es ca. 21-22 sek ..... (aber es hängt sich nicht auf).

ich werde das Thema mal vertiefen <g>


;-) thomas, too

[tomaten]

Wenn ich Deine Query so sehe, muss ich das auch gleich mal testen. Meiner hat einen Join und enthält eine Hierarchiche Abfrage, bei der auch noch in den Leveln sortiert wird. Daran sollte es aber nicht liegen. Manuell funktioniert die Abfrage, in Win32 und warum nicht in .NET? :shock: Ich werde die auch erstmal mit einem simplen "SELECT" testen.

[tomaten]

So habe das Ganze mal mit einem einfachen Select getestet. Das besondere ist, dass die Delphi.NET Assembly in einer ASP.NET 2.0 Anwendung läuft. Vielleicht liegt da ja das Problem begraben! :wall:

[Elvis]

Zitat:

Zitat von tomaten

So habe das Ganze mal mit einem einfachen Select getestet. Das besondere ist, dass die Delphi.NET Assembly in einer ASP.NET 2.0 Anwendung läuft. Vielleicht liegt da ja das Problem begraben! :wall:

Mich juckt es in dem Thread schon von Anfang an das zu fragen...
Warum kannst du deine DAOs nicht einfach als richtige .Net Klassen gegen StiNo ADO.Net Zugriffsklassen programmieren?
Sollte doch ohne weiteres möglich sein ohne den restlichen VCL Code plattzumachen. So wie ich es sehe scheinst du ja glücklicherweise nicht auf diesem Cross-Compile-Trip zu sein. ;)

[tomaten]

Ich teile mir den Code mit einer Win32 Anwendung! Stelle diese gerade Stück für Stück auf .NET um. Aber der Kern wird von beiden verwendet, kompiliere ihn also einmal Win32 und einmal .NET! Und der ist verdammt gross! ;) Will den Code auch nicht doppelt pflegen, da ich die Umstellung während laufender Weiterentwicklungen machen muss. Kurzum: habe lange ne andere Lösung gesucht. Es gibt aber keine zeitlich machbare. Ausserdem benutzt ich viele TDataSet basierte Memtables. Ich stelle z.Zt. nur die GUI auf ASP.NET um, dann den Rest. Man sollte doch meinen, dass dbExpress.NET in V3 (D8-D2006) einwandfrei funktioniert!