Firebird und Delphi 2005

[Robert_G]

Zitat:

Zitat von Christof

Ado.net nicht so gern, da Probleme mit großen Datenmengen.
Wie geht das mit dem Firbird .net unter delphi bzw. c#.

Den kapiere ich jetzt nicht. :gruebel:
Solange du Collections/Listen statt einem DataSet benutzt, sollte es sehr flott sein. ;)

Zitat:

Zitat von Christof

Habe den .net Provider installiert und dann ?

Du scheinst mit c# noch nicht so vertraut zu sein. (Sonst hättest du das wohl gewusst ;) )
Mache am besten erst die Tutorials aus der SDK Doku, die geben einen guten Überblick.
btw: Das hatten wir indirekt schon: http://www.delphipraxis.net/internal...=267347#267347

[Christof]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Christof

Ado.net nicht so gern, da Probleme mit großen Datenmengen.
Wie geht das mit dem Firbird .net unter delphi bzw. c#.

Den kapiere ich jetzt nicht. :gruebel:
Solange du Collections/Listen statt einem DataSet benutzt, sollte es sehr flott sein. ;)

Was heißt sehr flott! Ich habe eine Datenbank mit einer Million Datensätze ! Ist dann immer noch schnell mit Collections/Listen?

Zitat:

Zitat von Christof

Habe den .net Provider installiert und dann ?

Zitat:

Zitat von Robert_G

Du scheinst mit c# noch nicht so vertraut zu sein. (Sonst hättest du das wohl gewusst ;) )

Das ist richtig fange gerade erst mit c# an.

Zitat:

Zitat von Robert_G

Mache am besten erst die Tutorials aus der SDK Doku, die geben einen guten Überblick.
btw: Das hatten wir indirekt schon: http://www.delphipraxis.net/internal...=267347#267347

Werde ich mir man anschauen.

Aber eine Kurzanleitung als Tutorial für Firebird wäre nicht schlecht. Ich denke das auch andere ähnliche Probleme haben werden.
Vielleicht etwas für die Tutorial-Ecke ?


Gruß
Christof

[Alexander]

Zitat:

Zitat von Christof

Aber eine Kurzanleitung als Tutorial für Firebird wäre nicht schlecht. Ich denke das auch andere ähnliche Probleme haben werden.

*meld* :mrgreen:
Wäre cool wenn das jemand etwas ausführlicher beschreibeng könnte :)

[Generalissimo]

Zitat:

Zitat von kiar

hallo christof,

da wird allgemein der Firebird net provider favorisiert, für den zugriff auf firebird auch ado.net sollte funktionieren.

also nimm den firebird net provider oder ado.net

Kann mir das bitte jemand erklären. Soweit ich weiß, ist der Firebird .Net Provider = ADO.NET. Er setzt in seiner Technologie direkt auf ADO.NET auf. Die Zugriffe werden wie beim SQL .NET Provider der im Framework direkt mit drin ist, native aufgesetzt.
Wo gibt es da nen Unterschied zwischen ADO.NET und FIREBIRD .NET PROVIDER?

[Robert_G]

Zitat:

Zitat von Christof

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Christof

Ado.net nicht so gern, da Probleme mit großen Datenmengen.
Wie geht das mit dem Firbird .net unter delphi bzw. c#.

Den kapiere ich jetzt nicht. :gruebel:
Solange du Collections/Listen statt einem DataSet benutzt, sollte es sehr flott sein. ;)

Was heißt sehr flott! Ich habe eine Datenbank mit einer Million Datensätze ! Ist dann immer noch schnell mit Collections/Listen?

Ich dnke mal, du wirst keine Million DS in eine Collection laden wollen, oder?
Wenn doch sollte man den Begriff "flink" relativieren. ;)
Das System.Data.DataSet ist deshalb so lahm, weil es eine Art Offline-Datenbank ist. Du kannst schließlich Foreign-Keys, prim. Keys & Co definieren. Das bedeutet immer eine Menge Overhead (auch wenn du nix davon in deinem DS verwendest.)
Außerdem boxt eine DataRow ständig die einzelnen Werte in ein Object und wieder zurück. -> Das ist in .Net ziemlich lahm. (für Wertetypen á la structs, int, enums, ...)
Bei einer Collection kannst du eine Klasse als Element definieren, die deinem Datensatz bzw. der Logik dahinter entspricht. -> weniger oder kein Boxing.
Außerdem kann man so hübsch type-safe arbeiten ohne sich ständig einen Wolf zu casten. :)

Zitat:

Zitat von Christof

Aber eine Kurzanleitung als Tutorial für Firebird wäre nicht schlecht. Ich denke das auch andere ähnliche Probleme haben werden.
Vielleicht etwas für die Tutorial-Ecke ?

Wohl nicht für FB speziell, aber ein kleines Round Up über die Verwendung von ADO.Net Providern, DataBinding, IList & ICollection wäre sicher vorteilhaft.
Vielleicht finde ich dafür nach meinem Urlaub Zeit und Lust. ;) (Wäre dann aber in c# nicht in Delphi.Net)

p.s.: ADO.Net ist ein nettes Wort, bedeutet aber nix weiter als eine Sammplung von Komponenten, die IDbConnection, IDbCommand & Co implementieren. Da sie nicht direkt ableiten müssen gibt es auch keine generelle Performancebremse (außer der Provider wurde etwas verlangsamt: siehe MS Oracle Provider und der "richtige" ODP ;) )

[Christof]

Danke für die ausführliche Antwort, wieder was gelernt :-)

Zitat:

Zitat von Robert_G

Ich dnke mal, du wirst keine Million DS in eine Collection laden wollen, oder?

Nein das nicht, aber es können schon viele sein so 10.000.

Zitat:

Zitat von Robert_G

Bei einer Collection kannst du eine Klasse als Element definieren, die deinem Datensatz bzw. der Logik dahinter entspricht. -> weniger oder kein Boxing.
Außerdem kann man so hübsch type-safe arbeiten ohne sich ständig einen Wolf zu casten. :)

Aber einmal muss ich doch das boxing benutzen wenn ich die 10.000 Datensätze in objekte verwandele, wie schnell ist das denn?

Zitat:

Zitat von Robert_G

Wohl nicht für FB speziell, aber ein kleines Round Up über die Verwendung von ADO.Net Providern, DataBinding, IList & ICollection wäre sicher vorteilhaft.
Vielleicht finde ich dafür nach meinem Urlaub Zeit und Lust. ;) (Wäre dann aber in c# nicht in Delphi.Net)

Das wäre super, in c# ist auch o.k, da ich die Logik in c# programmieren wollte und nur für die Formulare Delphi .NET verwenden wollte.

Mich würde vor allem das ausführen von Stored Procedures und die Behandlung der Daten von Stored Procedures interessieren.

Da ich alles über Stored Procedures holen wollte. Weniger Netzbelastung.


Gruß
Christof

[Robert_G]

Ich hatte ein tutorial versprochen...
Mal ein kleines Update dazu:
Demnächst kommt ein Update für die DP (um sie an .Net und D2005 anzupassen) ich hoffe, dass in dem Zuge gleich noch eine Änderung an den Tutorials gemacht wird.
Da der Datenbank Zugriff in .Net wirklich verdammt einfach und auch sehr dynamisch sein kann, will ich euch das nicht vorenthalten, aaabeeer....
Damit man möglichst einfach und dyn. auf Datenbanken zugreifen muss man schon ein paar Vorkenntnisse in Hinsicht auf Reflection mitbringen.
Das erste Tut wird sich also um ein wenig Reflection drehen, danach kommt eins zu DataBinding und Collections.
Darauf aufbauend kann ich dann ein wenig über Datenbankzugriffe plaudern. ;)

Die ersten beiden Themen sind alles andere als trivial (zumindest bevor es einmal *Klick* gemacht hat), deshlab muss ich mir erstmal überlegen, wie ich das am geschicktesten rüberbringe.
Die Verzögerung durch das DP-Update kommt mir also nur Recht. :mrgreen:

[Alexander]

Zitat:

Zitat von Robert_G

Ich hatte ein tutorial versprochen...
Mal ein kleines Update dazu:
Demnächst kommt ein Update für die DP (um sie an .Net und D2005 anzupassen) ich hoffe, dass in dem Zuge gleich noch eine Änderung an den Tutorials gemacht wird.
Da der Datenbank Zugriff in .Net wirklich verdammt einfach und auch sehr dynamisch sein kann, will ich euch das nicht vorenthalten, aaabeeer....
Damit man möglichst einfach und dyn. auf Datenbanken zugreifen muss man schon ein paar Vorkenntnisse in Hinsicht auf Reflection mitbringen.
Das erste Tut wird sich also um ein wenig Reflection drehen, danach kommt eins zu DataBinding und Collections.
Darauf aufbauend kann ich dann ein wenig über Datenbankzugriffe plaudern. ;)

Die ersten beiden Themen sind alles andere als trivial (zumindest bevor es einmal *Klick* gemacht hat), deshlab muss ich mir erstmal überlegen, wie ich das am geschicktesten rüberbringe.
Die Verzögerung durch das DP-Update kommt mir also nur Recht. :mrgreen:

Wenn du das hinbekommen kannst, wäre das wirklich :thuimb:

[kiar]

hallo Robert,

zeit wird es :mrgreen: ,

da ich die woche nicht online sein kann, werde ich mir reflection aus meinen Büchern rauslesen.
also ich hoffe ich bin dann up to date :mrgreen:

bis denne

raik