TDataSet -> System.Data.DataSet Bridge?

[tomaten]

Hallo, hat einer eine Möglichkeit gefunden Daten aus einem TDataSet in ein .NET DataSet zu schieben oder diese zu verbinden. Das würde die Umstellung auf .NET (im Besonderen auf ASP.NET) sehr erleichtern, da nur die DataSet's gewechselt werden müssten, die mit einer sichtbaren ASP.NET Komponente verbunden sind und die als Source ein System.Data.DataSet erwarten. Hat da Borland gepennt und diese Verbindung vergessen? Ich habe noch nichts gefunden, selbst Dr. Bob meinte, man müsse alles überarbeiten! Aber nicht bei meiner Projektgrösse! Kann nicht monatelang darüber abtauchen! dbExpress gibt es ja schliesslich weiter als dbExpress.NET! Wer will schon freiwillig diesen ADO-Kram benutzen?

[Bernhard Geyer]

Zitat:

Zitat von tomaten

Hallo, hat einer eine Möglichkeit gefunden Daten aus einem TDataSet in ein .NET DataSet zu schieben oder diese zu verbinden. Das würde die Umstellung auf .NET (im Besonderen auf ASP.NET) sehr erleichtern, da nur die DataSet's gewechselt werden müssten, die mit einer sichtbaren ASP.NET Komponente verbunden sind und die als Source ein System.Data.DataSet erwarten. Hat da Borland gepennt und diese Verbindung vergessen? Ich habe noch nichts gefunden, selbst Dr. Bob meinte, man müsse alles überarbeiten! Aber nicht bei meiner Projektgrösse! Kann nicht monatelang darüber abtauchen! dbExpress gibt es ja schliesslich weiter als dbExpress.NET! Wer will schon freiwillig diesen ADO-Kram benutzen?

Borland hat nicht gepennt. Die Konzepte von ADO.NET und TDataset sind zu unterschiedlich.
TDataset arbeitet im verbundenen Zustand, ADO.NET ohne aktive DB-Verbindung. Und ADO.NET ist bei richtiger Verwendung um Welten mächtiger als das was Borland schon seit Jahren mit TDataset bietet.

Und wenn Du schon auf ASP.NET wechselt, so überarbeite deine DB-Schnittstelle auch gleich mit. Oder schreib dir ein Transformer-Klasse die sowas macht (evtl. 'ne Idee für ein OpenSource/Sourceforge-Projekt).

[Robert_G]

Ist es nicht möglich einen Dekorator über ein System.Data.DataSet zu stülpen, der von einem "TDataSet" ableitet und somit die "Übersetzung" übernimmt?
Wäre es nicht außerdem möglich einfach in den Vorgängern deiner Klassen (welche TDatasets konsumieren) den Typen und das handling zu ändern?
Und wenn du schon dabei bist: Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer.... :? )

[tomaten]

Zitat:

Zitat von Robert_G

Ist es nicht möglich einen Dekorator über ein System.Data.DataSet zu stülpen, der von einem "TDataSet" ableitet und somit die "Übersetzung" übernimmt?
Wäre es nicht außerdem möglich einfach in den Vorgängern deiner Klassen (welche TDatasets konsumieren) den Typen und das handling zu ändern?
Und wenn du schon dabei bist: Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer.... :? )

Naja viel akzeptieren .NET Klassen als DataSource ja nicht. Bei ADO.NET und connectionless DB wirds mir übel, wenn ich an den Overhead bei ein paar tausend SQL-Abfragen pro Sekunde denke. Vielleicht denke ich auch falsch, aber ich bin froh, dass dbExpress eine ständige Verbindung zur DB hält. Ich wollte auch eine Wrapper-Klasse bauen, damit ich nicht jeden .Eof, .Next, FieldByName usw. ersetzen muss, aber es muss doch auch einfacher gehen. Ich kann doch da nicht der Einzige mit diesem Problem sein!?

[Generalissimo]

Zitat:

Zitat von tomaten

Wer will schon freiwillig diesen ADO-Kram benutzen?

Zitat:

Zitat von Bernhard Geyer

Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer....

Was habt ihr alle immer nur gegen das DataSet von .Net Ich finde das übelst praktisch.
ADO.NET <> ADO das muss man auch erst verstehen. Es hat sich dabei einiges verändert.
Zumal .NET bzw. gerade ADO.NET nicht auf Client-Server-Szenarien, wie tomaten in seinem Projekt vorgeht, ausgerichtet ist.
In .Net 2.0 kommt noch ne "Binärkomprimierung" hinzu.

Das mit dem Dekorator ist ne gute Idee. Allerdings würde ich beim Umstieg auf das Verbindungslose Web (was ASP.NET definitv ist)
wirklich drüber nachdenken vom alten Client-Server-Prinzip zum N-Tier-Prinzip überzuwechseln. Wird dir in der Zukunft mehr Erfolg bringen.

Achso. Ganz vegessen. Vielleicht bringt dir der Link was:

Zitat:

Zitat von BDN

Or, since we have the very cool VCL for .NET, we can simply not do any conversion of code whatsoever, and simply do it this way:

Delphi-Quellcode:

Table1.First;
  while not Table1.EOF do begin
    ListBox1.Items.Add(Table1['NAME']);
    Table1.Next;
  end;

http://bdn.borland.com/article/0,1410,31996,00.html

[tomaten]

Zitat:

Zitat von Generalissimo

Allerdings würde ich beim Umstieg auf das Verbindungslose Web (was ASP.NET definitv ist)
wirklich drüber nachdenken vom alten Client-Server-Prinzip zum N-Tier-Prinzip überzuwechseln. Wird dir in der Zukunft mehr Erfolg bringen.

Wo steht geschrieben, dass Web sei verbindunglos? Ich mache ausschliesslich Webanwendungen und die sind alles andere als verbindunglos und wahnsinnig schnell. Irgendwann muss ich nun mal aktuelle Daten lesen und schreiben (damit bin ich auch ohne ADO.NET sparsam, aber in der Summe kommt da immer noch reichlich zusammen)! Und wo sollen da also noch x Schichten hin? Man kann es echt übertreiben, wo nicht Not am Mann ist! Browser = UI, Webserver = Bussiness-Logik, DB-Layer, DB ...! Ist für meinen Geschmack ausreichend! Wir wollen die auch nicht weiter als über's Web "verteilen"! Da auch unsere DB auf Klassen basiert (also quasi keine festen Strukturen wie üblicherweise hat) ist schneller DB-Traffic das "A" und "O"! Dabei graut es mir vor den ständigen ADO.NET Verbindungsaufbauten!

[Bernhard Geyer]

Zitat:

Zitat von tomaten

Naja viel akzeptieren .NET Klassen als DataSource ja nicht. Bei ADO.NET und connectionless DB wirds mir übel, wenn ich an den Overhead bei ein paar tausend SQL-Abfragen pro Sekunde denke.

:gruebel: Und wieso das? Du holst auch unter ADO.NET jeden Datensatz einzeln. Du verwendest jedoch keine Serverseitigen Curser mehr. Was übrigens auch von der Serverlast her seine Vorteile bietet (vor allem bei MS-SQL-Server, welche für jeden Serverseitigen Curser eine temporäre Tabelle füllen muss, da ja das Multi-Version-Konzept fehlt

Zitat:

Zitat von tomaten

Vielleicht denke ich auch falsch, aber ich bin froh, dass dbExpress eine ständige Verbindung zur DB hält.

dbExpress ist ein ganz schlechtes Beispiel. Du mußt um die Datenmenge in beiden Richtungen durchlaufen zu können erst die Daten in ein TClientDataset kopieren. Und da bist du eigentlich schon wieder bei disconnected Datasets.

Disconnected heißt primär nicht das du nach jeder Abfrage die DB-Verbindung beendest (wird auch nicht bei ASP.NET gemacht. Da wird sie in den Connection-Pool gelegt), sondern das das Ergebnis deiner Abfrage keine DB-Verbindung mehr benötigt und z.B einfach auf einen anderen Rechner übertragen werden kann (N-Tier-Anwendungen) oder gespeichert werden kann.

Zitat:

Zitat von tomaten

Ich wollte auch eine Wrapper-Klasse bauen, damit ich nicht jeden .Eof, .Next, FieldByName usw. ersetzen muss, aber es muss doch auch einfacher gehen. Ich kann doch da nicht der Einzige mit diesem Problem sein!?

Vielfach ist es kein großes Problem wenn die DB-Schnittstelle an wenigen Stellen konzentriert ist. So ist bei einem großen Projekt (1 Mio. Codezeilen) die DB-Schnittstelle (mit TDataset-Abhängikeiten) in wenigen 100 Zeilen in einer Unit konzentriert und alles andere läuft mit eigenen (disconnected) Datenklassen. Ein wenige wie ADO.NET, jedoch nicht so flexibel und mächtig.

@Generalissimo: Du hast mich fälschlicherweise zitiert.

[tomaten]

Zitat:

Zitat von Bernhard Geyer

:gruebel: Und wieso das? Du holst auch unter ADO.NET jeden Datensatz einzeln. Du verwendest jedoch keine Serverseitigen Curser mehr. Was übrigens auch von der Serverlast her seine Vorteile bietet (vor allem bei MS-SQL-Server, welche für jeden Serverseitigen Curser eine temporäre Tabelle füllen muss, da ja das Multi-Version-Konzept fehlt

Naja, ich benutze zu 90% Oracle! ;)

Zitat:

Zitat von Bernhard Geyer

dbExpress ist ein ganz schlechtes Beispiel. Du mußt um die Datenmenge in beiden Richtungen durchlaufen zu können erst die Daten in ein TClientDataset kopieren. Und da bist du eigentlich schon wieder bei disconnected Datasets.

:) Mach ich fast niemals. Hauptsächlich Select's.

Zitat:

Zitat von Bernhard Geyer

Disconnected heißt primär nicht das du nach jeder Abfrage die DB-Verbindung beendest (wird auch nicht bei ASP.NET gemacht. Da wird sie in den Connection-Pool gelegt), sondern das das Ergebnis deiner Abfrage keine DB-Verbindung mehr benötigt und z.B einfach auf einen anderen Rechner übertragen werden kann (N-Tier-Anwendungen) oder gespeichert werden kann.

Also Cursorless. Kann nicht gleich mal jemand zum Thema kommen? Endlich mal ne klare beruhigende Ausssage. Anders mach ich das bisher auch nicht!

Zitat:

Zitat von Bernhard Geyer

Vielfach ist es kein großes Problem wenn die DB-Schnittstelle an wenigen Stellen konzentriert ist. So ist bei einem großen Projekt (1 Mio. Codezeilen) die DB-Schnittstelle (mit TDataset-Abhängikeiten) in wenigen 100 Zeilen in einer Unit konzentriert und alles andere läuft mit eigenen (disconnected) Datenklassen. Ein wenige wie ADO.NET, jedoch nicht so flexibel und mächtig.

So ähnlich ist das bei mir, aber ich habe einfach die Zeit nicht. Umstellung von Win32 "Express WebFramework" auf .NET "ASP.NET" wird auch schon genug Arbeit und es wird ständig weiterentwickelt! Also muss man das doch mal zur Diskussion bringen! :D ;) Ich suche doch einfach nur nach Möglichkeiten nicht alles auf einmal umzustellen! Dann kann ich ja gleich noch 450.000 Zeilen Code von Delphi in C# übersetzen! ;)

[tomaten]

Zitat:

Zitat von Generalissimo

Zitat:

Zitat von BDN

Or, since we have the very cool VCL for .NET, we can simply not do any conversion of code whatsoever, and simply do it this way:

Delphi-Quellcode:

Table1.First;
  while not Table1.EOF do begin
    ListBox1.Items.Add(Table1['NAME']);
    Table1.Next;
  end;

http://bdn.borland.com/article/0,1410,31996,00.html

Ist ja ganz spannend, wenn man die manuell durchlaufen will, ich rede aber von den "automatischen" also denen die einem Grid oder sonstigem als Source dienen!

[Robert_G]

Zitat:

Zitat von Generalissimo

Zitat:

Zitat von Bernhard Geyer

Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer....

Was habt ihr alle immer nur gegen das DataSet von .Net Ich finde das übelst praktisch.

Es speichert seinen Inhalt in Object, somit gibt es IMMER Boxing/Unboxing wenn du auf einen value type darin zugreifst -> pfui deivel! ;) Ich habe kein Problem mit Boxing durch das Binden an UI Elemente, ist ja nur UI. Aber wenn ich beim Verarbeiten, validieren, whatsoever ständig rumboxen müsste... :shock:
Es programmiert sich auch ekelhaft dagegen. ;)

Ich persönlich setze lieber auf normale Klassen, die mit Hilfe von Metadaten und einem kleinen (selbst geschriebenen :) ) Enhancer in der Lage sind, selbstständig mit der DB zu "reden". DataSets wären doch IMHO viel zu umständlich und dieses DataAdapter-Gefriemel wäre mir auch zu ... friemelig. :mrgreen:

Zitat:

Zitat von Generalissimo

ADO.NET <> ADO das muss man auch erst verstehen. Es hat sich dabei einiges verändert.
Zumal .NET bzw. gerade ADO.NET nicht auf Client-Server-Szenarien, wie tomaten in seinem Projekt vorgeht, ausgerichtet ist.

Zitat:

Zitat von Generalissimo

In .Net 2.0 kommt noch ne "Binärkomprimierung" hinzu.

Du kennst schon den BinaryFormatter? :gruebel:
Was du da als Vorteil von 2.0 ansiehst, benutze ich schon lange um meine Deltas zwischen den Tiers zu übertragen. ;)

Was mich jetzt wirklich interessieren würde, wäre mehr, ob man Thomas' "DB Aware"-Klassen nicht anhand weniger Basisklassen, ganz unten in seinem Code, überzeugen könnte mit .Net Containern zu reden?

[Bernhard Geyer]

Zitat:

Zitat von Robert_G

Was mich jetzt wirklich interessieren würde, wäre mehr, ob man Thomas' "DB Aware"-Klassen nicht anhand weniger Basisklassen, ganz unten in seinem Code, überzeugen könnte mit .Net Containern zu reden?

Ein solcher Ansatz müßte ähnlich dem Wrapper der ADOExpress/dbGo-Komponenten sein, wo ja die ADO-Schnittstelle ins TDataset-Korset gequetscht wurde. Ist jedoch Aufgrund des unterschiedlicheren Konzepts von ADO.NET schwiriger und vermutlich auch inperformanter zu realsieren.

[tomaten]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Robert_G

Was mich jetzt wirklich interessieren würde, wäre mehr, ob man Thomas' "DB Aware"-Klassen nicht anhand weniger Basisklassen, ganz unten in seinem Code, überzeugen könnte mit .Net Containern zu reden?

Ein solcher Ansatz müßte ähnlich dem Wrapper der ADOExpress/dbGo-Komponenten sein, wo ja die ADO-Schnittstelle ins TDataset-Korset gequetscht wurde. Ist jedoch Aufgrund des unterschiedlicheren Konzepts von ADO.NET schwiriger und vermutlich auch inperformanter zu realsieren.

Naja, die Performance ist nicht so schlimm, es sind ja nur ein paar Daten in Grids oder Füllungen von SELECT's und die werden ja nicht alle auf einmal angezeigt und vorher auch selektiert.

@Robert_G
Endlich mal einer dem das Handling von ADO.NET genauso spanisch vorkommt, wie mir. Wenn man vernüftig mit SQL umgehen kann, liebt man doch den einfach TSQLQuery. Und wenn ich im Web Daten sichbar machen muss, hau ich die in eine kbmMemTable die ich auch temporär auf die Platte legen kann und wenn die Seite erneut aufgerufen wird (evtl. durch Umsortierung im Grid) sehr schnell wieder geladen werden kann. Nur auch die kbmMemTable.NET ist von TDataSet abgeleitet und muss irgendwie an die ASP.NET Komponenten gebunden werden, womit wir wieder am Anfang wären ... :(

[tomaten]

Huhu! :wiejetzt:
Keiner mehr da. Ich stell die Frage mal anders, da mir System.Data.DataSet recht neu sind. Kennt einer eine einfache Methode die Rekords aus einem TDataSet in ein System.Data.DataSet-Tabelle zu schieben? Das würde ja schon reichen. Nimmt zwar ein bisschen den Speed aber auch nicht wirklich merklich.

[Robert_G]

Probiere doch erstmal ICOmponent, und IEnumerable in deinen TDataSets zu implementieren.
Ersteres gibt dir Designtime support und letzteres ist die simopelste Form von List DataBinding.
Wenn das funktioniert würde ich dir eine Implementierung von IBindingList empfehlen, damit hat der BindingContext und BindingManager sämtliche Infos, die er brauchen kann. ;) (IEnumerable füllt dir nur ein Listen control, ohne dir die Möglichkeit zu geben, wie es das macht.

[tomaten]

So, nachdem ich ein handhabbares (keine Ahnung wie das nach neuer deutscher Rechtschreibung richtig ist ...) DataSet habe (mit First, Last, Next, Prior, Bof, Eof, FieldByName, RecNo, RecordCount ... usw.) habe ich nur noch ein Problem. Wie erkenne ich, ob ein Feld "null" ist. Das gute .IsNull existiert ja natürlich bei Microsoft auch nicht. Und (DataSet.Table.Row.Item == null) funktioniert auch nicht! :(
Weiss es zufällig jemand?

[Robert_G]

Dann steht entweder null oder DbNull.Value drin ;)

[tomaten]

Zitat:

Zitat von Robert_G

Dann steht entweder null oder DbNull.Value drin ;)

Supi DBNull.Value funktioniert. Hast Du irgendwann mal das SDK verschluckt oder bist Du seit Stunde 0 bei .NET? ;) Danke.

Eine andere Frage. Warum bekomme ich dabei immer einen Oracle Fehler (ORA-00936: Ausdruck fehlt)?:

Delphi-Quellcode:

OleDbCommand Command1 = new OleDbCommand;
Command1.CommandText = "SELECT * FROM MyTable WHERE MyID <> @MyID";
Command1.Parameters.Add("@MyID", OleDbType.Integer).Value = 0;
OleDbDataReader DataReader = Command1.ExecuteReader();

[Robert_G]

"@" ist dieses augenkrebsverursachende Ding, weshalb ich TSQL nicht leiden kann.
Oracle hält es da standardmäßig bei einem Retinafreundlichen ":". ;)
Falls du den OleDbProvider nimmst um unabhängig von der DB zu sein musst du dir also überlegen, wie du die Parameterpräfixe anpasst. ;)
Wobei konsequentes Verwenden der ADO.Net interfaces und eine Factory für die richtige Connection auch nicht dumm wären. ;)
Hast du einmal eine Connection in der Hand, hast du alle nötigen Factories für Commands, Parameter und DataReader zur Hand:

Code:

IDbConnection connection = DeineFactory.GetInstance(connectionString);
IDbCommand command = connection.CreateCommand();
IDataParameter parameter = command.CreateParameter();
command.Parameters.Add(parameter);
IDataReader dataReader= command.ExecuteReader();

Zitat:

Hast Du irgendwann mal das SDK verschluckt oder bist Du seit Stunde 0 bei .NET?

Eigentlich bin ich ziemlich spät aufgesprungen. ;)
Aber wenn man bedenkt wie straightforward und logisch die APIs in .Net aufgebaut sind, weiß man entweder genau wo man suchen muss, oder es ergibt sich von selbst. ;)

[tomaten]

Hm, wenn man von dbExpress kommt, kommt man nichtmal auf die Idee, dass das "@" DB-abhängig ist. Bei dbExpress ist es ja immer ":" und die Parameter werden automatisch erzeugt. Es ist also noch ein langer Weg ... vom Luxus zu ADO.NET! ;)

[tomaten]

Mist, sobald ich eine Doppelpunkt vor die Variable setze crasht die Anwendung und will gleich alles an Microsoft melden :D ! Nochmal die IDE sagt dazu was! :(

[Robert_G]

Ich glaube hier wird's langsam Zeit für einen neuen Thread. Und wenn dann schreibe auch was zickt. Zum Beispiel dass du einen ORA-XXX bekommst oder was auch immer...

[tomaten]

Zitat:

Zitat von Robert_G

Ich glaube hier wird's langsam Zeit für einen neuen Thread. Und wenn dann schreibe auch was zickt. Zum Beispiel dass du einen ORA-XXX bekommst oder was auch immer...

Ach wenns das wäre wärs schön. Crash richtig schön, vom allerfeinsten ohne Meldung, nur ob ich das an M$ senden möchte.

[tomaten]

Hier mal der "Crashcode":

Delphi-Quellcode:

OleDbConnection Connection = new OleDbConnection();
Connection.ConnectionString = "Provider=\"MSDAORA.1\";User ID=JOU;Data Source=DB;Persist Security Info=True;Password=gibts";
Connection.Open();
OleDbCommand Command = Connection.CreateCommand();
Command.CommandText = "SELECT * FROM \"TABLE\"\n";
Command.CommandText += "WHERE \"THEID\"<>:THEID";
Command.Parameters.Add(":THEID", OleDbType.Integer).Value = 0;
OleDbDataReader DataReader = Command.ExecuteReader();

Passiert gleichmässig völlig indentisch in Delphi 2005 und #Develop. Mit "?" anstelle von ":THEID" im SQL geht es, aber so kann man ja nicht arbeiten.