Programm mit alter MDAC Version kompilieren
verwendetes Datenbanksystem: MS Access
Hallo zusammen,
ich bekomme folgende sinngemäße Fehlermeldung beim Zugriff auf MS Access:
"Es wurde nur die MDAC Treiber Version 2.51 gefunden, gebraucht wird 2.6"
Leider ist es dem Kunden unmöglich eine neue Version von MDAC zu installieren.
Gibt es eine Möglichkeit mein Programm mit der MDAC Version 2.51 zu kompilieren?
Vielen Dank
sonnige Grüße
mrdjoker
Na damit das Programm ordentlich mit der Access DB kommunizieren kann.
Zur Zeit ist es beim Kunden einfach nicht lauffähig.
Alle .NET Anwendungen, die Datenzugriff Funktionalität verwenden, erfordern MDAC 2.6 oder höher (empfohlen wird MDAC 2.7).
Steht sinngemäß auf einer der Microsoft-Support-Sites 😉
http://support.microsoft.com/kb/315467
Also glaub ich wirds schwierig das anders zum laufen zu bringen.
Mfg,
Daniel
So ein Mist!
Da bleibt mir wohl nichts anderes übrig, als auf XML zurück zu greifen.
Um mit einer Access DB zu kommunizieren braucht es kein ADOX.
Der Jettreiber und ADO.NET kommen eigentlich ganz gut ohne das aus.
Also nochmal was machst Du, das Du meinst das brauchen zu müssen.
Mein Programm ist ein Mitarbeiter Arbeitszeiterfassungstoool.
Es werden also nur ein paar Inserts, Update und Delete Statements abgeschickt.
Ich benutzte OLEDB:
public int ManipulateDB(string queryString)
{
int result = 0;
using (OleDbConnection sqlConn = new OleDbConnection(MyConString))
{
OleDbCommand sqlCmd = new OleDbCommand(queryString, sqlConn);
sqlConn.Open();
result = sqlCmd.ExecuteNonQuery();
sqlConn.Close();
}
return result;
}
[...] Leider ist es dem Kunden unmöglich eine neue Version von MDAC zu installieren. [...]
Wieso das?
Ich benutzte OLEDB [...]
Warum?
[...] Da bleibt mir wohl nichts anderes übrig, als auf XML zurück zu greifen.
Und andere sinnvolle Alternativen wie z.B. SQLite oder Firebird kommen warum nicht in Frage?
Zu 1. Der Kunde hat über 1000 PCs herumzustehen, da ist es wirtschaftlicher mein Tool den Gegebenheiten anzupassen, als umgekehrt.
Zu 2. Warum OLEDB: Weil Access laut versch. Foren am performantesten via OLEDB kommunizieren kann.
Zu 3. SQLite oder Firebird werden doch auch mit Api's aus der MDAC angesprochen?
Wenn ich dich richtig verstehe soll ich die Connection einfach mal via ODBC aufbauen?
Ich hoffe mal, dass ich dann keine Meldung bekomme, dass Version 2.6 benötigt wird.
Ich teste das mal morgen..
zu 1)
Es ist deine Aufgabe bei Projektbeginn dafür zu sorgen das entweder der Kunde durch ein Setup die "richtigen" Komponenten bekommt, oder du die richtige Datenbank benutzt.
Sorry, aber wer für so einen großen kunden am Schluss über so etwas nachdenkt, handelt gegen seine eigenen Interessen und schadet ( wie viele vor ihm ) unserem Berufstand.
zu 2) Access als richtige Datenbank zu bezeichnen ist eigentlich schon falsch. Und natürlich ist Access mit OleDB am schnellsten, aber das auch nur weil OleDB ( durch Kompatibilitätslayer ) ohnehin sehr lahm ist.
zu 3)
Nein SQLite hat seinen eigenen ADO.NET Provider der Lokal läuft, der hat überhaupt keine Verbindung zum MDAC. Genauso gilt das für FireBird.
Und ODBC ist definitv die Falsche Richtung.
SQLite oder Firebird werden nicht über MDAC angesprochen. Diese Datenbank besitzen einen eigenen ADO.NET Provider.
@ FZelle
Wer sagt denn, dass ich am Schluss über so etwas nachdenke?
Ich habe dem Kunden gerade mal einen Prototypen gegeben.
Ich versteh trotzdem was du meinst 😉
Machen wir uns nichts vor, eine richtige Datenbank sollte zumindestens Rollbacks durchführen können,
schon allein aus dem Grund ist MS Access eher eine Spiele-Datenbank.
Gibt es nun einen Weg, wie ich trotzdem MS Access benutzen kann, ohne MDAC updaten zu müssen?
Der Vorteil an Access ist nämlich, dass die Daten mit Office-Mitteln leicht weiter verarbeitet werden können, daher würde ich nur ungern auf Access verzichten.
Vielen Dank schon mal für euer Feedback.
Wie schon oben erwähnt, gibt es keine andere Möglichkeit. Wenn es nur darum geht das man das es in Excel und Co. eiterverarbeitet werden soll, dann exportiere es als Excel aus deiner Datenbank raus und benutze alles andere außer Access als lokale Datenbank. Wobei mit gerade auffällt, dass du von 1000 Benutzern gesprochen hast - dann solltest du doch auch keine lokale Datenbank sondern einen SQL Server benutzen. Das ist auf jedenFall besser aus jeder Hinsicht.
Hast du ernsthaft vor 1000 User mehr oder weniger gleichzeitig auf eine Access DB zugreifen zu lassen?
Da wünsch ich dir mal viel Spass.....
Natürlich greifen nicht alle 1000 Benutzer auf eine Access DB zu.
Jeder hat eine lokale zu liegen.
Und warum? Hat es einen größeren Sinn denn ich gerade nicht sehe?
Hat keinen größeren Sinn 😉
Das soll nur nen kleines Hilfstool für die Mitarbeiter sein, eine zentrale Datenbank ist dafür nicht notwendig.
Dann würde ich über nichts anderes als SQLite überhaupt nur nachdenken...
Klingt äußerst seltsam.
Ich kenne keine einzige Firma, die sich ein Zeiterfassungstool bauen lässt und das nur als Hilfe für die Mitarbeiter einsetzen will, wobei mir auch da die Hilfe nicht ganz klar ist.
Solche Dinge haben einen derart grossen Nutzen in verschiedenste Richtungen(Urlaubsplanung, Gehaltsabrechnung, Verrechnung zum Kunden usw), dass ich als grössere Firma mit 1k Mitarbeitern sowas sowieso brauche, oder rechnen die Gehälter per Hand ab?
Also da Geld beim Fenster rauss zu werfen, auf die Idee würde ich ja gar ned kommen.
Meine Empfehlung: Ein Termin mit der Firma und ma n ernsthaftes Gespräch führen.