Problem mit ODBC Datenbankverbindung

Guten Morgen,

beim Verbindungsaufbau zur Datenbank kommt folgende Fehlermeldung
Das Format der Initialisierungszeichenfolge stimmt nicht mit der Spezifikation überein, die bei Index '0' beginnt.

Hier der Code

public static string Members(string m_name)
        {
            string mname = null;

            using (var connection = new OdbcConnection("Program.DB_DSN"))
            {
                connection.Open();
                using (var command = new OdbcCommand("SELECT m_name FROM mask WHERE login = '" + m_name + "'", connection))
                {
                    using (var dr = command.ExecuteReader())
                    {
                        while (dr.Read())
                        {
                            mname = dr.GetString(0);

                        }
                        return mname;
                    }
                }
            }
        }

Mit der Fehlermeldung kann ich leider nichts anfangen ... wo liegt das Problem? Kann mir jemand helfen? Wäre super!

Es scheint doch nicht an der DB-Verbindung zu liegen.
Wenn diese auskommentiert ist, tritt der Fehler trotzdem auf.

Welcher Teil einer Win-Forms Anwendung wird als erstes ausgeführt (die "Start Form" oder gibts es davor einen weiteren Code)? Damit nachvollzogen werden kann, an welcher Stelle der Fehler auftritt.

Waschmolch schrieb:

Welcher Teil einer Win-Forms Anwendung wird als erstes ausgeführt (die "Start Form" oder gibts es davor einen weiteren Code)? Damit nachvollzogen werden kann, an welcher Stelle der Fehler auftritt.

In der main-Funktion startet die Anwendung.

Sobald eine nicht gefangene Exception auftritt, hält das Visual Studio doch an der richtigen Stelle an. Suchen ist doch eigentlich garnicht notwendig

geeky

OdbcConnection conn=new OdbcConnection("Program.DB_DSN");
conn.Open();

...wenn das schon nen Fehler wirft, würde ich davon ausgehen das er die Datenquelle nicht öffnen kann.

Mögliche Ursachen:
ConnectionString falsch (probier mal den direkt statt "Program.DB_DSN" anzugeben).
64bit/32bit Probleme:
- .net-Anwendung läuft als 64bit-App, aber der ODBC-Treiber ist in 64bit nicht verfügbar
- .net-Anwendung läuft als 32bit-App, aber "Program.DB_DSN" ist nur im "ODBC Data Source Administrator" in der 64bit-Version eingerichtet.

c:\windows\system32\odbcad32.exe = 64bit-Version
c:\windows\SysWOW64\odbcad32.exe = 32bit-Version

...ich würde ODBC vermeiden, sofern möglich und stattdessen auf nen ADO.NET Datenbanktreiber aufsetzen!

Sobald eine nicht gefangene Exception auftritt, hält das Visual Studio doch an der richtigen Stelle an. Suchen ist doch eigentlich garnicht notwendig

Das stimmt natürlich! Entschuldige! Bin da im Code leider durcheinander gekommen .... und die Meldung hängt auch tatsächlich mit dem DB-Zugriff zusammen.

Ebenfalls vermute ich inzwischen, dass es ein Problem bezüglich 32/64 Bit ist.
Hab die Anwendung über den Konfigurationsmanager nun für 32bit (x86) und 64bit (x64) Plattform erstellt - aber keine Änderung.

...ich würde ODBC vermeiden, sofern möglich und stattdessen auf nen ADO.NET Datenbanktreiber aufsetzen!

Warum? Was sind dabei die Vorteile/Nachteile?

Wenn direkt der System-DSN eingetragen wird, funktioniert es (obwohl der Name in der Variablen Program.DB_DSN korrekt ist).

Dravere

Waschmolch schrieb:

Wenn direkt der System-DSN eingetragen wird, funktioniert es (obwohl der Name in der Variablen Program.DB_DSN korrekt ist).

Mich beschleicht ein Gefühl und es verstärkt sich, wenn ich das hier lese. Ist der Connection-String in der statischen Variable DB_DSN der Klasse Program gespeichert? Würde es dann womöglich wie folgt funktionieren:

// ...
using (var connection = new OdbcConnection(Program.DB_DSN))
// ...

Man beachte die fehlenden Gänsefüsschen.

Grüssli

geeky

Program.DB_DSN sieht da wirklich verdächtig aus - mit Stichwort "Variable" erst Recht

Gründe für ADO.Net:
- Sofern für die verwendete Datenbank ein Managed Treiber existiert könnte der aufgrund weniger pinvokes schneller sein (muss aber nicht)
- Es ist einfach "frischer" und ich persönlich gehe davon aus das die Hersteller langfristig mehr in ADO.NET als in ODBC-Treiber investieren werden.

(Ich mag außerdem den ODBC Data Source Administrator nicht - Unnötiger Konfigurationärger.
Meiner Meinung nach sollten Anwendungen sich bei der Installation oder beim erstem Start selbst ums einrichten von Datenbanken kümmern und mich nicht damit belästigen)

Dravere

geeky schrieb:

- Es ist einfach "frischer" und ich persönlich gehe davon aus das die Hersteller langfristig mehr in ADO.NET als in ODBC-Treiber investieren werden.

Den Punkt sollte man vielleicht zumindest dahingehend relativieren, dass dies nur für .Net gilt. ODBC wird überall eingesetzt und ist ein defacto Standard. ADO.NET betrifft nur die .Net Welt.

geeky schrieb:

(Ich mag außerdem den ODBC Data Source Administrator nicht - Unnötiger Konfigurationärger.
Meiner Meinung nach sollten Anwendungen sich bei der Installation oder beim erstem Start selbst ums einrichten von Datenbanken kümmern und mich nicht damit belästigen)

Das ist doch genauso mit ODBC möglich? Hängt nur von der Applikation ab.

ADO.NET ist einfach die Datenbankschnittstelle, welche für die .Net Welt erstellt wurde. Es ist schon fast logisch, dass diese natürlich besser ist als ein allgemeiner Standard, welcher für alle Sprachen und Arten des Datenbankzugriffes erstellt wurde.

Grüssli

Ihr hattet Recht - es wurde als String und nicht als Variable übergeben *schäm*
Tut mir leid ...

Da hier dann aber der Vorschlag aufkam doch besser einen .Net Datenbanktreiber anstatt ODBC zu verwenden kam und folgende Idee:

Einträge (User, PW, Server) in der Registry und diese dann beim Programmstart auslesen. Funktionieren tut es auch bereits.
Trotzdem würde ich gerne wissen, was Ihr davon haltet ... ist das eine gute Lösung?