Guten Morgen,
Du siehst an den "überwältigten" Reaktionen, dass es gar nicht so einfach ist. Da ich bei meinem Arbeitgeber in den letzten Monaten dasselbe mitgemacht habe, ein paar Kriterien, die wir angelegt haben:
Da Zeit=Geld, Geld immer knapp und Zeit noch knapper ist, haben wir uns entschieden weiterhin mit Delphi 7 zu produzieren. Delphi 2007 werden wir uns wieder genau anschauen und evtl. darauf umsteigen, aber immer noch
Win32. Sollten wir irgend wann zu dem Ergebnis kommen, dass .NET für unsere Arbeit geeignet ist, dann werden wir umsteigen. Allerdings bedeutet das, einige Anwendungen, die seit ca. 6 Jahren entwickelt werden, mit der Zeit umzustellen. Unsere Kunden interessiert das in keinster Weise, wie die Anwendung gemacht wurde, wichtig ist nur dass sie stabil läuft! Somit müsste der Vorteil für die Entwicklung schon immens sein!
Für mich privat gibt es auch noch keinen Grund auf .NET zu wechseln, von der Tatsache mal abgesehen, dass es mehr freie Stellen als .NET (C#/VB#) Entwickler gibt als Delphi-Stellen. Insofern muss ich, wenn ich irgend wann mal nicht arbeitslos sein will, mich mit .NET beschäftigen.
Zur Datenbank: Du hast kein Geld, deine Kunden haben kein Geld (wollen keines ausgeben) - also für mich sieht das stark nach einer, in der Anschaffung kostenlosen Datenbank aus.... Da ich Firebird kenne und sehr gern damit arbeite, sehe ich das vielleicht auch etwas einseitig. Nur kann man meiner Meinung nach bei Firebird nur wenige Fehler machen, damit
FB zu einem Sicherheitsrisiko für einen Server wird. Bei
MSSQL ist es nach meinem Gefühl eher anders rum. Firebird läuft sogar auf alten Maschinen selbst als Server, da hast Du mit
MSSQL vermutlich schon eher mal ein Problem.
Für den Zugriff auf Firebird gibt es meiner Meinung nach 3 Alternativen: UIB (kostenlos), FIBPlus (kostet was) oder Zeos (kostenlos) [in genau der Reihenfolge]. Wegen Deiner Angst bzgl. Fremdkomponenten: Klar solltest Du Wildwuchs vermeiden und nicht zig verschiedene Bibliothekten einbinden. Aber warum auf etwas verzichten, dass dir die Arbeit wesentlich vereinfacht und eine entsprechende Performance bieten?
Beispiel TTreeView. Das Ding von Borland ist bei einer entsprechenden Datenmenge so stinke langsam, dass es schon fast einem Verbrechen gleichkommt das Ding zu nutzen. Als Alternative setze ich VirtualStingView ein, das ich teilweise sogar als Grid "missbrauche", eben weil es so schnell ist.
Wichtig bei der Komponenten ist eher, dass Du den Zugriff auf den Source erhälst. Somit kannst Du auch selbst Änderungen vornehmen bzw. von anderen vornehmen lassen.
Desweiteren kannst Du die Abhängigkeit von den Komponenten auflösen, indem Du deine Anwendung entsprechend aufbaust und eine Mehrschicht-Architektur verwendest. Somit kannst Du im Notfall die komplette
VCL-Oberfläche wegwerfen und eine ASP.NET Oberfläche dran basteln, ohne Änderungen an der GEschäftslogig vornehmen zu müssen, weil diese in entsprechende Klassen gekapselt ist und nichts mit der Oberfläche zu tun hat.
Lemmy