Datenbank austauschen (Access durch Mictosoft SQL-DB ersetzen)

verwendetes Datenbanksystem: Access 2003

Hallo Profis,

ich habe eine prinzipielle Frage. Ich entwickle meine Methoden derzeit mit OleDb und entsprechend sieht der Code aus. Es werden ja explizit Objekte mit "OleDbXXXXX" beschrieben, bzw. man bedient sich eben der OleDb-Klassen. Könnte jedoch auch z. B ODBCXXXX verwenden oder SQLXXXX.

Diese generischen Schnittstellen sind doch genau dafür da, um es z. B. später einfach zu ermöglichen, die Datenbank dahinter ohne Änderung auszutauschen.

Wenn ich jedoch die Access DB durch zb eine SQL-Datenbank mit derselben Struktur ersetze, dann müsste ich doch auch die ganzen Codezeilen von OleDbXXXX durch SQLXXXX ersetzen oder nicht? Die SQL-Klassen sind doch explitit für Microsoft SQL-Datenbanken. Verstehe irgendwie den Sinn nicht.

Bin für jede Aufklärung dankbar.

Grüße

Hallo,

Wenn ich jedoch die Access DB durch zb eine SQL-Datenbank mit derselben Struktur ersetze, dann müsste ich doch auch die ganzen Codezeilen von OleDbXXXX durch SQLXXXX ersetzen oder nicht?

Ja, musst Du.

Stattdessen kannst Du auch DbXXX nehmen. Es muss trotzdem Code für jede Datenbank geschrieben werden.

Beispiel : http://www.seven-c.de/files/datenbankenhowto.htm#10 Kapitel 11

Wenn Du Datenbank-unabhängig programmieren willst dann schau Dir die O/R-Mapper an, z.B. Entity Framework.

Grüße Bernd

Hey,

vielen dank für den Link, der ist sehr informativ. Allerdings auch schon etwas älter, hat sich da nichts getan?

Weiterhin wird da ODBC als Möglichkeit erwähnt unabhängig zu programmieren. Stimmt das? In den ODBC-Einstellungen in Windows kann man eine SQL oder Oracle Datenbank auswählen, funktioniert dann der Code noch, wenn man OdbcDataAdapter etc. verwendet und die AccessDB zb durch eine MicrosoftSQL-DB ersetzt hat?

Ich habe die Vorgabe, ein DB-Projekt datenbankneutral zu entwickeln. Das Projekt ist datenbanktechnisch wie gesagt nicht sehr komplex, jedoch kennt man das spätere Zieldatenbanksystem nicht und ich habe keine Zeit meine Klasse in mehreren Ausführungen zu entwickeln zumal ich es auch gar nicht testen kann.

Ergänzung:

Im Internet (Galileo Openbook) stoße ich auf folgende Aussage:
"Während der OleDb- bzw. Odbc-Datenprovider eine datenbankunabhängige Syntax erlaubt, ist der SqlClient-Provider für den SQL Server gedacht, der benannte Parameter mit diesem Präfix unterstützt"

Weiterhin bin ich auf
"Datenbankunabhängige Programmierung mit der DbProviderFactory in ADO.NET 2.0" gestoßen.

Wie sind denn jetzt die Möglichkeiten für mich? Es ist irgendwie alles ein großes Durcheinander habe ich das Gefühl.

Vielen Dank nochmal.

huhu,

vielen dank für den Link, der ist sehr informativ. Allerdings auch schon etwas älter, hat sich da nichts getan?

Naja, Grundlegend muss doch alles beim alten bleiben, oder?

Von ODBC würde ich generell abraten: alt, langsam, existiert nur noch aus Kompatibilitätsgründen.

Dass die Zieldatenbank nicht bekannt ist, ist extrem ärgerlich, denn man muss trotz allem die eigentlichen DB-Statements (Insert, Update etc.) Datenbankspezifisch halten. Hier kommt man also nie um eine Anpassung auf eine bestimmte DB herum.

Dafür gibt es aber OR-Mapper:

Wenn Du Datenbank-unabhängig programmieren willst dann schau Dir die O/R-Mapper an, z.B. Entity Framework.

😃

Xynratron

Ah mist jetzt hast du meine Änderung nicht mehr gelesen, haben zeitgleich gepostet 8o

Weiterhin wird da ODBC als Möglichkeit erwähnt unabhängig zu programmieren.

Da steht aber auch :

Rausgekommen ist allerdings eine langsame und umständliche Lösung, die sehr eingeschränkt ist, weil sie nur den kleinsten gemeinsamen Nenner unterstützt.

Ich sollte noch dazuschreiben dass man ODBC auf keinen Fall verwenden sollte.

DbFactory ist ein guter Ansatz. Für eine Datenbank-unabhängige Programmierung braucht man aber noch mehr.

vielen dank für den Link, der ist sehr informativ. Allerdings auch schon etwas älter, hat sich da nichts getan?

ADO.NET ist nach wie vor aktuell. In meinem Text fehlt allerdings noch ein Beispiel mit dem Entity Framework.

Grüße Bernd

Ok, scheinbar hab ich jetzt ein echtes Problem.

Ich hab bereits eine Klasse mit vielen Methoden programmiert, die mit Access zusammenarbeitet. Die Schnittstelle ist OleDb. Vorher war sie ODBC, das habe ich im Nachhinein geändert mit Suchen und Ersetzen, da ich die Providerspezifischen Klassen nutze.

Scheinbar ist ja ODBC ein absolutes "NoGo". Ich arbeite mit Dataadaptern, wäre es viel Aufwand die Methoden mit dem DbFactory-Ansatz umzuschreiben? Verhalten sich die Adapter gleich oder gibt es bei der "übersetzung" Dinge, die man beachten muss?

Wäre die Umschreibung auf O/R Mapper aufwändig? ist das EntityFramework im dotNetFramework 4.0 mit drin oder muss man das extra installieren?

Ok, scheinbar hab ich jetzt ein echtes Problem.

Es gibt keine Probleme, es fehlt nur ein Stück zur Lösung (Spanisches Sprichwort)

Ich hab bereits eine Klasse mit vielen Methoden programmiert, die mit Access zusammenarbeitet. Die Schnittstelle ist OleDb. Vorher war sie ODBC, das habe ich im Nachhinein geändert mit Suchen und Ersetzen, da ich die Providerspezifischen Klassen nutze.

Dann ändere mit Suchen/Ersetzen in Sql... oder Db..., z.B. so :

 DbCommand cmd = new SqlCommand();

Wäre die Umschreibung auf O/R Mapper aufwändig? ist das EntityFramework im dotNetFramework 4.0 mit drin?

Ja und Ja.

Grüße Bernd

Super! Ich bin grad dabei die Klassen entsprechend anzupassen. Zum glück kein großer aufwand. Da ich keine speziellen SQL Befehle verwende, sollte es bei einem Austausch der Access DB zu keinen größeren Problemen kommen.

Allerdings verwende ich das rowupdated-Event von der OleDbDataAdapter-Klasse, das jedoch in dem DbDataAdapter nicht drin ist. Ich brauche das aber, um den Primärschlüssel aus dem hinzugefügten Datensatz in einer verknüpften Tabelle einzufügen (mit SELECT @@IDENTITY).

Wie krieg ich das denn jetzt implementiert? 🤔

Vielen Dank noch mal.....

INSERT INTO meineTabelle (Bearbeiter, Zeitpunkt, Anzahl) 
OUTPUT INSERTED.meinPK 
VALUES (@dBearbeiter, @dZeitpunkt, @Anzahl);

oder

INSERT INTO meineTabelle (Bearbeiter, Zeitpunkt, Anzahl) 
OUTPUT INSERTED.meinPK 
VALUES (@dBearbeiter, @dZeitpunkt, @Anzahl);
SELECT TOP 1 meinPK FROM meineTabelle
WHERE Bearbeiter = @dBearbeiter ORDER BY meinPK DESC;

Ich arbeite mit DataAdaptern und wüsste nicht, wie da das Output-Verfahren funktioniert. Unterstützt Access das überhaupt?

Das andere Problem mit dem Event habe ich mit einem Cast durchgeführt, obwohl mir das echt unschön erscheint, aber scheint nicht anders zu funktionieren.

Vielen Dank auf jedenfall, das hat mir schon viel weiter geholfen! Ich habe auch mal spaßeshalber auf ODBC umgestellt (jetzt gehts ja einfach) und tatsächlich muckt ODBC schon teilweise bei den Datentypen rum. Da muss man tatsächlich entweder händische Abfragen machen zwischen den Systemen, etwas robuster programmieren oder gleich auf die O/R-Technik wechseln.

Hätte gerne mal ein schönes beispiel dafür, aber im Netz findet man irgendwie nicht wirklich viel darüber.

Grüße

Hallo sharpType,

Beispiel für O/R Mapping oder für Datenbank-Unabhänige SQLs?

Gruß
Juy Juka