Veröffentlicht 15. Februar 200718 j Ich greife mit Hilfe von ADO.NET (ODBC-Provider) auf eine Oracle 9i DB zu. Die Methode dataAdapter.Fill(ds) dauert bei mir bis zu 10 Sekunden! Wenn ich dieselbe SELECT-Abfrage im Oracle SQL Developer ausführe benötigt sie max. 0,4 Sekunden. Wie kann ich das Problem beheben? Ist der Treiber allg. so langsam?
15. Februar 200718 j hab eigentlich das selbe problem; ich denke einfach, dass das ado.rs schlecht ist; da gibts ja was neues in .net... wie das genau hinhaut, weis ich leider nicht
15. Februar 200718 j Ich benutze nicht das alte RecordSet sondern das DataSet von ADO.NET (dataAdapter.Fill(ds)).
15. Februar 200718 j Ich greife mit Hilfe von ADO.NET (ODBC-Provider) auf eine Oracle 9i DB zu. warum ODBC nimm doch OLEDB
15. Februar 200718 j Die Idee hatte ich auch schon, aber dazu müsste ich mein komplettes Projekt umschreiben. Gibt es denn keine andere Möglichkeit das zu beschleunigen? Ist der Treiber wirklich so langsam?
15. Februar 200718 j hm ich hab dem letzt eine sql abfrage nur mit odbc realisiert .. ganz ohne ado.net und es ging einwandfrei. performence probleme hat ich dabei ebenfalls keine... Dim MyConString As String = "DRIVER={MySQL ODBC 3.51 Driver};" & _ "SERVER=XXXXXXXXXX;" & _ "DATABASE=XXXXXXXXXX;" & _ "UID=XXXXXXXXXX;" & _ "PASSWORD=XXXXXXXXXX;" & _ "OPTION=3;" Dim MyConnection As New OdbcConnection(MyConString) MyConnection.Open() Dim MyCommand As New OdbcCommand MyCommand.Connection = MyConnection MyCommand.ExecuteNonQuery() MyConnection.Close() Catch ex As System.Data.Odbc.OdbcException MessageBox.Show(ex.ToString) End Try
15. Februar 200718 j welche version von ADO.NET (respektive, welches framework) verwendest du? welchen ODBC-treiber verwendest du - den von Oracle oder den von MS? wenns möglich ist, poste doch auch davon die versionsnummer. versuche auch mal, das ODBC-logging und/oder SQL*Net tracing zu aktivieren. es macht im übrigen oftmals sinn - und ist auch tatsächlich realisierbar - dass eine anwendung sowohl für ADO.NET als als für ODBC.NET funktioniert. dass du dir aus nachvollziehbaren gründen allerdings die arbeit nicht antun willst, erscheint logisch. s'Amstel
15. Februar 200718 j welche version von ADO.NET (respektive, welches framework) verwendest du? welchen ODBC-treiber verwendest du - den von Oracle oder den von MS? wenns möglich ist, poste doch auch davon die versionsnummer. versuche auch mal, das ODBC-logging und/oder SQL*Net tracing zu aktivieren. es macht im übrigen oftmals sinn - und ist auch tatsächlich realisierbar - dass eine anwendung sowohl für ADO.NET als als für ODBC.NET funktioniert. dass du dir aus nachvollziehbaren gründen allerdings die arbeit nicht antun willst, erscheint logisch. s'Amstel Verwende das .NET Framework 2.0 unter Visual Studio 2005 Express, außerdem verwende ich den Microsoft ODBC Treiber (Microsoft ODBC for Oracle, 2.575.1117.00, MSORCL32.DLL). Habe das mit dem Logging mal versucht. Dazu muss man doch im ODBC Data Source Administrator (Administrative Tools) das Tracing aktivieren? Oder geht das an anderer Stelle? Weil der schreibt bei mir kein Logfile. Sorry, bin noch neu auf dem Gebiet. Schon mal vielen Dank für die Unterstützung!
15. Februar 200718 j Dazu muss man doch im ODBC Data Source Administrator (Administrative Tools) das Tracing aktivieren? ja. Oder geht das an anderer Stelle? nein, ausser direkt über die entsprechenden registry-einstellungen. eine andere möglichkeit ist das von mir angesprochene tracing des oracle-client (sqlnet.log o.ä.). Weil der schreibt bei mir kein Logfile. das ist manchmal ein gefrickel - u.u muss der pfad zur sql.log angepasst werden und IMO auch manchmal die zu loggende anwendung neu gestartet werden. siehe auch -> How To Generate an ODBC Trace with ODBC Data Source Administrator und verlinkte KB-artikel. s'Amstel
19. Februar 200718 j Das mit dem DataReader werde ich mal ausprobieren wenn ich so nicht mehr weiter komme! Habe es immer noch nicht geschafft das ODBC Tracing zu aktivieren. Verwende in meinem Programm auch keinen System / User DSN als Datenquelle, sondern verbinde mich direkt über einen ConnectionString. Ist das der Fehler? Das Tracing des Oracle-Clients kann ich leider auch nicht laufen lassen. Habe hier keinen Oracle-Client installiert.
19. Februar 200718 j Verwende in meinem Programm auch keinen System / User DSN als Datenquelle, sondern verbinde mich direkt über einen ConnectionString. Ist das der Fehler? kannst du den connectstring hier bitte mal posten? allenfalls um sensitive daten entschärft. Das Tracing des Oracle-Clients kann ich leider auch nicht laufen lassen. Habe hier keinen Oracle-Client installiert. wie greifst du ohne installierten oracle client auf oracle zu? s'Amstel
19. Februar 200718 j Das Programm soll nachher auch auf PCs läuffähig sein, auf welchen kein Oracle-Client installiert ist. Deswegen dachte ich mir nehme ich den ODBC-Treiber von Microsoft. Hier der "entschärfte" ConnectionString: strCon = "Driver={Microsoft ODBC for Oracle};server=servername;uid=username;pwd=geheim"
20. Februar 200718 j Die Idee hatte ich auch schon, aber dazu müsste ich mein komplettes Projekt umschreiben. Kleiner Tipp: Benutz Interfaces, dann fällt dieses Problem weitgehend geringer aus und zu musst nurnoch sehr wenige spezifische Codestellen anpassen wenn Du mal was umstellen willst. IDbConnection, IDbCommand, IDbDataAdapter ... Gruß Markus
22. Februar 200718 j Oder nimm den .NET Provider von Oracle (ODP.NET), dann haste eine OracleConnection, OracleCommand usw... http://www.oracle.com/technology/tech/windows/odpnet/index.html
22. Februar 200718 j Oder nimm den .NET Provider von Oracle (ODP.NET), dann haste eine OracleConnection, OracleCommand Benutz das ganze in Verbindung mit den Inderfaces, dann kannst die Provider nach belieben austauschen. IDbConnection connection = new OracleConnection ... IDbConnection connection = new OleDbConnection ... IDbConnection connection = new OdbcConnection ... IDbConnection connection = new SqlConnection ...
22. Februar 200718 j Inderfaces Es ist nicht das gemeint was da steht, ich meinte natürlich Interfaces
22. Februar 200718 j Und zwar war nicht der Microsoft ODBC-Treiber schuld, sondern ich hatte versehentlich "dataAdapter.MissingSchemaAction = MissingSchemaAction.AddWithKey" eingestellt. :hells: Werde jetzt bei dem Microsoft ODBC-Treiber bleiben. Einfach deshalb, weil das Programm dann auf jedem XP-Rechner mit installiertem .NET Framework 2.0 lauffähig ist und der Oracle-Client nicht zwangsweise installiert werden muss. Außerdem bin ich mit der Performance jetzt sehr zufrieden! Nochmal vielen Dank für Eure Untersützung!
Archiv
Dieses Thema wurde archiviert und kann nicht mehr beantwortet werden.