TDataSet -> System.Data.DataSet Bridge?

[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! :(