Forum: PC-Programmierung vs studio 2022

Karl K. schrieb:
> Liegt es an mir

Vermutlich

> oder ist vs2022 fehlerbehaftet?

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:

> Ich bekomme die mdb-Datenbank nicht i8n die c#-WPF-Form.

Wenn's mit VS2010 klappt, warum verwendest Du das nicht einfach weiter?

Harald K. schrieb:
> 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).

Karl K. schrieb:
> Programme, die ständig weiterentwickelt
> werden, mit einer veralteten software zu schreiben, ist ein gewisses
> Risiko.

Offenbar wurde bei Dir schon sehr, sehr lange nichts mehr 
weiterentwickelt, sonst würdest Du nicht alle möglichen Versionen des 
Visual Studio überspringen.

> vs2022 ist 64bit - vs2010 ist 32bit

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.

Karl K. schrieb:
> für mdb-Datenbanken
> möglicherweise nicht kompatibel.

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.

Karl K. schrieb:
> vs2022 ist 64bit - vs2010 ist 32bit - für mdb-Datenbanken
> möglicherweise nicht kompatibel.

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 ...

Jim M. schrieb:

> Denn AFAIK kann man Access (zumindest früher) nur entweder als 32 Bit
> oder als 64 Bit Version installieren, aber nicht beides zugleich.

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.

Frank E. schrieb:
> Ist denn Access zwingend als DB gesetzt? Es gibt ja auch nicht wenig
> Alternativen ...

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.

Karl K. schrieb:
> 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

Karl K. schrieb:
> Frank E. schrieb:
>> Ist denn Access zwingend als DB gesetzt? Es gibt ja auch nicht wenig
>> Alternativen ...
>
> Nein - access deswegen weil, in meinem Buch "c#-Datenbanken" Access als
> erstes Beispiel vorkommt. Erstes Beispiel - erstes Problem.

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.

Karl K. schrieb:

> 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

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?