[C#] Oledb connectie naar MySQL database.

[urk_forever]

Hallo allemaal,

Ik probeer met een OleDBConnection verbinding te maken met een MySQL database. Hiervoor heb ik de Connector/Net 5.1.5 van MySQL geinstalleerd en als reference toegevoegd aan mijn project. Vervolgens gebruik ik deze connection string:

Provider=MySql.Data.MySqlClient;Data Source=database;User Id=user;Password=pw;Server=server

Vervolgens probeer ik deze code uit te voeren:

C#:

OleDbConnection _OleConnection = new OleDbConnection(ConfigurationSettings.AppSettings["OleDBConnectionString"]);
_OleConnection.Open();

Nu krijg ik de volgende melding:

De MySql.Data.MySqlClient-provider is niet geregistreerd op de lokale computer.

Maar volgens mij moet dit toch kloppen, wat doe ik fout??

[whoami]

Wat bevat die connector precies ?

't lijkt me dat die 'connector' wel een class zal bevatten waarmee je een connectie moet maken met MySQL ipv OleDb te gebruiken ?

Edit:
lijkt me wel dus:

All you need to do is download Connector/Net which is a fully-managed ADO.NET driver written in 100% pure C#. Download the installer and install Connector/Net.

After setting up a provider, you need to create a connection to the database. You do this by using the MySqlConnection object.

When creating an instance of MySqlConnection, you supply the provider in it’s constructor.

MySqlConnection mysqlCon = new MySqlConnection(strProvider);

klik

[ Voor 72% gewijzigd door whoami op 18-04-2008 21:51 ]

[sig69]

^^
Je wil met MySQL verbinden, dus waarom gebruik je een OleDnConncetion opv een MySqlConnection?

[urk_forever]

Crap, dus dan moet je weer MySQL specifieke componenten gebruiken dat hebben ze weer apart bedacht. Dan moet ik toch maar connectie maken via ODBC.

Dan mijn vervolg vraag, als ik ik deze connectie string "Provider=System.Data.Odbc;Dsn=cenm" gebruik om connectie te maken naar MySQL dan zegt hij dat de provider System.Data.Odbc niet geregistreerd is. Maar die zit toch standaard in .Net framework? Of moet ik dan Microsoft.Data.Odbc gebruiken??

@Sig69: Omdat ik later dezelfde lib ook wil gebruiken met bijvoorbeeld Oracle, of MSSQL Server. Dus ik wil generieke componenten gebruiken

[ Voor 13% gewijzigd door urk_forever op 18-04-2008 22:24 ]

[LinuX-TUX]

urk_forever schreef op vrijdag 18 april 2008 @ 22:24:
Crap, dus dan moet je weer MySQL specifieke componenten gebruiken dat hebben ze weer apart bedacht. Dan moet ik toch maar connectie maken via ODBC.

Dan mijn vervolg vraag, als ik ik deze connectie string "Provider=System.Data.Odbc;Dsn=cenm" gebruik om connectie te maken naar MySQL dan zegt hij dat de provider System.Data.Odbc niet geregistreerd is. Maar die zit toch standaard in .Net framework? Of moet ik dan Microsoft.Data.Odbc gebruiken??

@Sig69: Omdat ik later dezelfde lib ook wil gebruiken met bijvoorbeeld Oracle, of MSSQL Server. Dus ik wil generieke componenten gebruiken

Wat let je om de Enterprise richting op te gaan? EntityManagers gebruiken en klaar

[roy-t]

urk_forever schreef op vrijdag 18 april 2008 @ 22:24:


@Sig69: Omdat ik later dezelfde lib ook wil gebruiken met bijvoorbeeld Oracle, of MSSQL Server. Dus ik wil generieke componenten gebruiken

Ik gebruik zelf ODBC en MySQL maar ik doe het op de volgende manier (zie code onder) ik gebruik dus wel het odbc component wat standaard in .Net zit, maar zover ik weet moet de driver wel specifieker zijn, maar goed ik zit er nog niet al te diep in

C#:

using System;
using System.Collections.Generic;
using System.Text;
using System.Data.Odbc;
using System.Windows.Forms;

//class gedoe en zo even geknipt//
 //Stel een connectie in via een connectionString
        public SQLConnection(string connectionString)
        {
            odbcConnection = new OdbcConnection(connectionString);
        }
        
        //Ga uit van de standaard MySQL ODBC driver waar deze applicatie voor gemaakt is en bouw een connectie
        //Naar aanleiding van de opgegeven ip's, poorten, databaes, users en wachtwoorden
        public SQLConnection(string adress, string port, string database, string user, string password)
        {
            odbcConnection = new OdbcConnection(
                "Driver={MySQL ODBC 3.51 Driver};" +
                "Server=" + adress.Trim() + ";" +
                "Port=" + port.Trim() + ";" +
                "Database=" + database.Trim() + ";" +
                "User=" + user.Trim() + ";" +
                "Password=" + password.Trim() + ";" +
                "Option=3;");           
        }

        //Creeeren een connectie maar nu ook als variabele de te gebruiken driver
        public SQLConnection(string driver, string adress, string port, string database, string user, string password)
        {
            odbcConnection = new OdbcConnection(
                "Driver={" + driver.Trim() + "};" +
                "Server=" + adress.Trim() + ";" +
                "Port=" + port.Trim() + ";" +
                "Database=" + database.Trim() + ";" +
                "User=" + user.Trim() + ";" +
                "Password" + password.Trim() + ";" +
                "Option=3;");
        }

[whoami]

urk_forever schreef op vrijdag 18 april 2008 @ 22:24:
Crap, dus dan moet je weer MySQL specifieke componenten gebruiken dat hebben ze weer apart bedacht. Dan moet ik toch maar connectie maken via ODBC.

Wat is het probleem om MySQL specifieke classes te gaan gebruiken ?
Ik vermoed dat je wil dat je applicatie met meerdere verschillende DBMS'en kan praten ? Indien dit idd zo is; weet dan wel dat gebruik maken van OleDb als 'generieke' methode zowiezo niet voldoende is. Ieder SQL dialect is nl. anders.

@Sig69: Omdat ik later dezelfde lib ook wil gebruiken met bijvoorbeeld Oracle, of MSSQL Server. Dus ik wil generieke componenten gebruiken

Ja dus.

Kijk, ik zou voor iedere DBMS dat je wil ondersteunen een aparte (specifieke) DAL bouwen, die dan gebruik maakt van specifieke componenten. Dat is zowiezo performance-wise ook meestal de beste keuze.
Daarnaast ontkom je niet aan de verschillen in SQL dialecten zoals ik eerder al aanhaalde. (LIMIT vs TOP, etc... ).

Maak een (of meerdere) interface waartegen je kan programmeren, en maak classes voor ieder DBMS dat je wil ondersteunen die die interface(s) implementeren.
In je programma gebruik je dan die interfaces (kijk eens naar strategy & abstract pattern).

[Niemand_Anders]

Euh, leest niemand meer de MSDN documentatie tegenwoordig? Alle database connecties implementeren DbConnection. ODBC is ontzettend traag en het gebruik van meerdere soort database is een slecht excuus om ODBC te gebruiken. ODBC moet je alleen als laatste redmiddel gebruiken als er geen NATIVE implementatie aanwezig is zoals het uitlezen van een Dbase of Excel bestand.

In alle andere gevallen is DbConnection, DbCommand, DbDataReader, etc. Kijk anders eens een keertje in de System.Data.Common namespace..

Onze DAL Business layers zijn database onafhankelijk en implementeren alleen objecten uit de common namespace. In de web/app.config wordt vervolgens aangeven welke type ingeladen (Activator.CreateInstance) moeten worden. Nadat bijvoor de MysqlConnection instance is geladen wordt deze daarna direct gecast naar een DbConnection instance.

[whoami]

Blijft het geval dat je SQL specifiek is voor iedere DB die je wil ondersteunen.
Waarom je dus in je DAL die MySql of SqlClient class gaat gaan casten naar de common DbConnection class is me een raadsel; je wint er nl. niets mee, want, als het goed is, komen die xxxConnection, xxxDataReader, etc... classes helemaal niet buiten je DAL.

[Niemand_Anders]

whoami schreef op zaterdag 19 april 2008 @ 18:48:
Blijft het geval dat je SQL specifiek is voor iedere DB die je wil ondersteunen.
Waarom je dus in je DAL die MySql of SqlClient class gaat gaan casten naar de common DbConnection class is me een raadsel; je wint er nl. niets mee, want, als het goed is, komen die xxxConnection, xxxDataReader, etc... classes helemaal niet buiten je DAL.

De SQL statements welke wij gebruiken voor Oracle is niet anders dan voor MSSQL of MySQL. Zolang je je aan de SQL2003 (of voorgaande) standaard houd kun je je query op vrijwel elke recente RDBS uitvoeren. En ja als je DB specifieke opties gebruikt kun je inderdaad niet wisselen van database, maar dat staat los van de gebruikte driver (native vs ODBC). Nogmaals, het gebruik van meerdere soorten database is een slecht excuus om ODBC te gebruiken.

Wat betreft DbCommand vs OleDbCommand: Je voert de query in beide gevallen op dezelfde database uit, alleen is de native implementatie een stuk sneller. De query veranderd niet omdat je ineens een andere 'driver' gebruikt. En het kan aan mij liggen, maar een simpele performance boost vind ik een hele goede reden om de common namespace te gebruiken ipv de ODBC (OleDB) varianten. De cast is nodig omdat de DAL *niet* weet welke database wordt gebruikt. Dat wordt namelijk gespecificeerd in een DataProvider sectie in de app/web.config. De DalHelper.CreateConnection maakt een instantie van het in de web.config opgegeven type, cast deze 'terug' naar DbConnection en returned deze aan de functie. Hetzelfde geld voor CreateCommand, CreateParameter, etc. Op basis hiervan hebben wij ook een LinqToDb provider kunnen schrijven.

[whoami]

Je 'downcast' naar de abstracte class waar je van inherit; zo bv:

code:

OleDbConnection theConnection;

DbConnection conn = (DbConnection)theConnection;

Echter, je 'conn' object blijft een OleDbConnection. Het is niet zo dat je je object plots veranderd in een DbConnection object (die is trouwens abstract). Je hebt nu gewoon een 'common interface' waar je tegen kunt aan praten. (polymorphisme anyone ? ).
Je maakt dus gewoon gebruik van het Liskov principe (wat goed is).

De SQL statements welke wij gebruiken voor Oracle is niet anders dan voor MSSQL of MySQL. Zolang je je aan de SQL2003 (of voorgaande) standaard houd

Als je je aan die standaard houd, dan beperk je jezelf imho nogal veel, en ga je waarschijnlijk soms moeilijke constructies nodig hebben die veel simpeler (en performanter) kunnen zijn als je DB-specifieke opties gebruikt.

Trouwens, als je meerdere DBMS'en wilt ondersteunen, waarom dan geen gebruik maken van een o/r mapper of een generator ?