Delphi oder VS-Studio bei FB1.5

[Hans Anzengruber]

Hallo,

ich würde gerne eine FB1.5 DB-Anwendung mit Visual-Studio unter .net
erstellen.
Bisher hatte ich nur die Konstellation Delphi7-IBO-FB1.0

Sollte ich bei der Delphi-Variante bleiben oder ist der Einsatz von
VS.net zu empfehlen.
Gibt es unter .net die Möglichkeit die IBO - Komponenten zu integrieren,
oder gibt es andere vergleichbare Komponenten ?

Bin für jede Empfehlung dankbar.

[Bernhard Geyer]

Willst Du unbedingt nach .NET welchseln?
Welche Vorteile versprichst Du dir bei einer "normalen" DB-Anwendung

[Hans Anzengruber]

Ich habe das Gefühl, daß das "alte" Delphi ein "Auslaufmodell" ist bzw. wird.
Daher wollte ich bei einem neuen Projekt auf .net setzen.

Oder handele ich mir mit der VS <-> FB Konstellation unnötige Probleme ein

[Bernhard Geyer]

> Ich habe das Gefühl, daß das "alte" Delphi ein "Auslaufmodell" ist bzw. wird.

Also in den letzten 3 Jahren haben wir erst einen Kunden gehabt der nach einer .NET-Lösung gefragt hat. Und wirklich Kriegsentscheident war noch nie.
Ich vermute mal das der richtige .NET-Zwang erst mit der nächsten Windows-Version und .NET 2.0 kommen wird.

Aber nichts destotrotz: Für eine .NET-Anwendung sollten wenn schon neu entwickelt sollten nur 100%ige ADO.NET-Provider verwendet werden. Und dieser werden die IBO-Komponenten nicht sein. Aber schau mal hier: <a href="http://firebird.sourceforge.net/index.php?op=devel&sub=netprovider">Firebird ADO.NET Data Provider</a&gt

[Hans Anzengruber]

Wenn ich das richtig interpretiere, ist demnach die Entwicklung unter .net
"zukunftssicherer".
Ich werde den ADO.NET Data Provider ausprobieren.

Kann man unter ADO.NET mit einer gleichen Performance rechnen

[Bernhard Geyer]

> Wenn ich das richtig interpretiere, ist demnach die Entwicklung unter .net "zukunftssicherer".

Kommt immer darauf an welche Anforderungen man hat. Für Windows-Entwicklung wird man schlecht darum herumkommen. Bloss ab wann es sinnvoll und ab wann es zwingend ist steht m.E. noch in den Sternen. Bei dem was ich gerade Entwickle ist Win32 mit VCL noch die beste Lösung.

> Kann man unter ADO.NET mit einer gleichen Performance rechnen ?

Eigentlich ja. Außer deine Implementierung ist zu sehr auf Connected Datasets mit Serverseitigen Curser ausgelegt. Dann wirst du einiges umbauen müssen

[Henry Krick]

Hallo Bernhard,

Was sind denn Connected Datasets? Gibt es doch unter Ado.net die möglichkeit das Client-Server-Prinzip bei DB's umzusetzen

[Bernhard Geyer]

Unter Connected Datasets meine ich die von Delphi/BDE verbundenden Datenmengen.
Unter ADO.NET ist der normalfall der disconnected. Sprich: Du forderst die Daten an, überträgst sie in ein ADO.NET-Dataset und beendest sofort wieder die Verbindung für diese Datenmenge:

Vorteil: Geringste DB-Server-belastung
Nachteil: Umbauarbeiten nötig, da es gegenüber dem bisherigen Verfahren (mit Serverseitigen Cursern und ähnlichen) absolut notwendig ist mit der minimalen Ergebnismenge zu arbeiten.

> Gibt es doch unter Ado.net die möglichkeit das Client-Server-Prinzip bei DB's umzusetzen?

Problemlos

[Bernhard Geyer]

Unter Connected Datasets meine ich die von Delphi/BDE verbundenden Datenmengen.
Unter ADO.NET ist der normalfall der disconnected. Sprich: Du forderst die Daten an, überträgst sie in ein ADO.NET-Dataset und beendest sofort wieder die Verbindung für diese Datenmenge:

Vorteil: Geringste DB-Server-belastung
Nachteil: Umbauarbeiten nötig, da es gegenüber dem bisherigen Verfahren (mit Serverseitigen Cursern und ähnlichen) absolut notwendig ist mit der minimalen Ergebnismenge zu arbeiten.

> Gibt es doch unter Ado.net die möglichkeit das Client-Server-Prinzip bei DB's umzusetzen?

Problemlos. Jedoch muß man sich etwas umgewöhnen