Zitat von
etom291272:
wie gesagt habe schon unzählige codezeilen in
ado für den
mssql (zur zeit
msde) server geschrieben. natürlich möchte ich jetzt nicht unbedingt den ganzen code und vielleicht sogar noch programmlogik umschreiben weil ich als datenbank interbase verwende.
Das klingt doch genau nach einem Grund für eine einheitliche Schnittstelle wie
ADO.
Ob
IB ausreichend ist, ist eine 2. Frage. Aber der Test ist ... krass.
Ich weiß nicht wie schlau es ist, sein Einkommen von solchen Dingen abhängig zu machen.
Außerdem dürfte das Transaktionshandling in
IB anders genug sein um dir Kopfschmerzen bereiten zu können.
Die reine
SQL syntax (
SQL 92/99) dürfte in beiden so ähnlich sein, dass du vielleicht sogar exakt die gleichen Statements fahren kannst.
IB hat keine Windows Authentifizierung. Das dürfte ein paar Dinge durcheinanderbringen.
Es wäre vielleicht angebracht sich über die Einschränkungen des
SQL Svr 2005 Express gegenüber dem großen
SQL Svr schlau zu machen. Der Express ist der Nachfolger der
MSDE, nicht mehr kostenlos, dafür auch nicht mehr so eingeschränkt.
Interessant am 2005'er sind natürlich .Net Stored procedures, typen, trigger,...
Im
MSDN findest du irgendwo ein Beispiel einer Klasse, die sich nach außen wie ein normaler VarChar verhält, doch automatisch per Rinjdael verschlüsselt abgelegt wird
Programmieren kannst du das in jeder .Net-Sprache die du bevorzugst...
Selbst wenn dein Client keine .Net App ist, innerhalb der
DB ist das eine wirklich coole Sache.
Ansonsten gibt's noch
Data Abstract, damit wärst du komplett unabhängig von
ADO oder der
DB.
btw: Finaler Release termin des
SQL Svr 2005 ist November, die Beta der Express gibt's im
MSDN zum Dowload.