|
Anzeige
|
vs studio 2022hallo, versuche mich gerade mit der Erstellung einer access-Datenbank. Mit vs2022 gelingt mir das trotz befolgen eines Tutorials nicht. Ich bekomme die mdb-Datenbank nicht i8n die c#-WPF-Form. Mit vs2010 geht es reklativ einfach. Hatte kürzlich die gleiche Problematik mit dem Mediaplayer in c#. Liegt es an mir oder ist vs2022 fehlerbehaftet?
Vermutlich
Unwahrscheinlich, jedenfalls auf dem Level nicht. Aber wenn die Fehlerbeschreibung so irre präzise ist, ist der Fehler mit sehr hoher Wahrscheinlichkeit irgendwo zwischen Stuhllehne und Tastatur zu finden:
Wenn's mit VS2010 klappt, warum verwendest Du das nicht einfach weiter?
Danke für diesen überaus witzigen und originellen Beitrag, der mir aber trotzdem nicht weiterhilft. Programme, die ständig weiterentwickelt werden, mit einer veralteten software zu schreiben, ist ein gewisses Risiko. vs2022 ist 64bit - vs2010 ist 32bit - für mdb-Datenbanken möglicherweise nicht kompatibel. Mit unterschiedlichen Entwicklerprogrammen zu arbeiten ist im Prinzip Murks. vs2010 daher nur dann, wenn vs2022 wirklich fehlerbehaftet ist. Wobei vs2010 für meine Belange völlig ausreichend ist und ich die nahezu unendlichen Möglichkeiten von vs2022 ohnehin nicht nutzen kann. Ich hätte daher gerne eine Einschätzungen von jemandem, der Datenbanken entwickelt und praktisch mit vs2022 arbeitet. Andere können ein mit VS2010 begonnenes Projekt mit neueren Versionen des Visual Studio fortsetzen, dazu müssen sie nur das Projekt mit der neueren Version laden. Das ist in der Regel die *.sln-Datein ("Solution"). Datenbanken kann man mit so vielen Entwicklungswerkzeugen auf so viele Arten und Weisen ansprechen, daß einem der Kopf qualmt. Du schriebst was von "Erstellen" einer Access-Datenbank - dafür braucht es gar kein Visual Studio, das macht man mit Access. Wenn Du auf eine solche Datenbank zugreifen willst, kannst Du das beispielsweise mit einem ODBC-Treiber machen; die Programmiersprache Deiner Wahl muss nur mit dem ODBC-Treiber sprechen können (d.h. der muss auch in der entsprechenden "Bittigkeit" vorliegen, ein 32-Bit-ODBC-Treiber ist aus einem 64-Bit-Programm heraus nicht nutzbar und umgekehrt).
Offenbar wurde bei Dir schon sehr, sehr lange nichts mehr weiterentwickelt, sonst würdest Du nicht alle möglichen Versionen des Visual Studio überspringen.
Vs2010 enthält keinen 64-Bit-Compiler, das aber tut jede neuere Version des Visual Studio, auch wenn die IDE selbst keine 64-Bit-IDE ist.
Vielleicht ist es genau andersrum: Dein Access oder was auch imemr ist 32-Bit-Code, und Du versuchst aus irgendwelchen Gründen, darauf mit 64-Bit-Code zuzugreifen, was, wie ich gerade schon anhand von ODBC schrieb, nicht geht. Allerdings enthält VS2022 selbstverständlich auch 32-Bit-Compiler, mit denen sich entsprechend auch 32-Bit-Programme erstellen lassen.
Damit könntest Du übrigens die Lösung gefunden haben. Denn AFAIK kann man Access (zumindest früher) nur entweder als 32 Bit oder als 64 Bit Version installieren, aber nicht beides zugleich. Ist aber schon eine Weile her seit ich damit ernsthaft was zu tun hatte. Windows Automation (ActiveX) kann notfalls zwischen 32- und 64 Bit Programmen kommunizieren, und das Access Zeuchs sollte per ActiveX weitgehend fernsteuerbar sein. Ist denn Access zwingend als DB gesetzt? Es gibt ja auch nicht wenig Alternativen ...
Das ist immer noch so. Und man kann mit der 32Bit-Version tatsächlich auch nur mit einem 32Bit-Programm interagieren (und entsprechend bei 64Bit). Aber: VS ist in der Lage, sowohl 32Bit als auch 64Bit-Programme zu generieren, jedenfalls ab Studio2012. Man muss ihm nur sagen, was man haben will. Bei .Net-Programmen ist es noch einfacher, die sind gleichzeitig 32Bit und 64Bit. Als was sie dann am Ende laufen, wird zur erst zur Laufzeit ausgekungelt, genauer: beim Start des Programms. Das entscheidet der Loader anhand der Verfügbarkeit der Abhängigkeiten. Allerdings gibt es gerade dadurch beim Zugriff auf Office u.U. ein Problem. Das passiert in aller Regel dann, wenn auf dem Zielrechner mal eine 32Bit-Version von Office installiert war, diese aber später durch eine 64Bit-Version ersetzt wurde und man zum Zugriff die Office-Interop-Komponenten verwendet. Dann sind die Interop-Komponenten für beide "Bittigkeiten" registriert und der Loader präferiert die falsche. Da muß man von Hand in der Registry nachbessern und die 32Bit-Registrierung für die Interop-Komponenten löschen. Bei Zugriff über OLEDB-Provider könnte sich im Prinzip dieselbe Situation ergeben. Aber scheinbar räumt MS hier besser auf, wenn man die Bittigkeit des Office ändert. Mir ist es jedenfalls noch nicht passiert, daß sich dieses Problem bei Zugriff über OLEDB ergab.
Nein - access deswegen weil, in meinem Buch "c#-Datenbanken" Access als erstes Beispiel vorkommt. Erstes Beispiel - erstes Problem. Ich habe zwar schon viel mit c# programmiert - aber Daten immer in *.txt - files gespeichert. Das reicht jetzt nicht mehr weil die Verknüpfung schwierig wird. Datenbanken sind für mich Neuland. Es geht im Prinzip um Mietverwaltung. Den Objekt-Dateien sollen wechselnde Mieter, Mietzahlungen aus Bank-csv-dateien, Stromverbräuche etc. zugeordnet werden. Die zutreffende Frage lautet daher, mit welchem Datenbankprogramm lässt sich dies am einfachsten umsetzen - wobei die Programmierung schon in c# erfolgen sollte.
Dann vergiss' Access, und nimm irgendeine einfache SQL-Datenbank. Da die Aufgabe eher trivial ist (keine große Datenbank, kein großer Durchsatz, keine komplexe Struktur), reicht auch sqlite. Das ist eine recht performante Datenbank ohne externe Serverprozesse, die in Zigtausend bis -millionen Anwendungen genutzt wird. Für das .Net-Geraffel gibt es da auch passende Unterstützung von MS: https://learn.microsoft.com/de-de/dotnet/standard/data/sqlite/?tabs=netcore-cli
Dann wäre die nächste Frage, ob das lokal an einem Arbeitsplatz passieren soll, oder ein Zugriff übers Netz wünschenswert ist. Bei Netzwerk wäre Sqlite nicht so geeignet, eher MySQL, MariaDB, MSSQL, Oracle ... etc. Könntest du dich gar entschließen, deine App mit ODBC/JDBC kompatibel zu machen, könntest du beinahe jedes beliebige SQL-DBMS benutzen (sofern du nur die "comon" Standard-SQL-Befehle verwendest). MySQL oder MariaDB laufen z.B. auch auf einem NAS (Synology oder QNAP), da muss nicht unbedingt "dicke" Server-Hardware dahinterstehen.
OK, also .Net. Bleibt immer noch eine Vielfalt von drei üblichen Möglichkeiten zum Zugriff auf Access-DBs. Welche davon nutzt "dein" Programm? Office-Interop oder OLEDB oder ODBC? Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
