Extension pour SQL Server

Bonjour,

J'ai démarré une nouvelle solution de type Application Windows Form en c# sous Visual Studio 2019, et je n'arrive pas à trouver les extensions pour utiliser l'outil

Code:

---

1 2	System.Data.SqlClient

---

Celui-ci ne contient que 2 options:

Code:

---

1 2 3 4

System.Data.SqlClient.SqlClientPermission et System.Data.SqlClient.SqlClientPermissionAttributes

---

mais point de

Code:

---

1 2	System.Data.SqlClient.SqlConnexion

---

et pas moyen de trouver ça sur le net.
Ou bien fallait-il démarrer le projet d'un autre type que Application Windows Form ?

Si en plus vous avez la solution pour MySql, ce serait super!

Merci.

Windows Form est tout à fait correct. Par contre vérifie la framework cible de ton projet. Regarde bien à être sur un framework .Net 4.x, et non pas sur un .Net Core 1.x ou 2.X


Pour MySql, il faudra télécharger et installer les packages adéquat sur le site officiel (je pense !) de MySql, ensuite tu aura un namespace du type System.Data.MySqlClient, il me semble.

Sinon, il faudra passer par System.Data.ODBC et une source ODBC connectée à ta base MySQL

Bonjour sevyc64,

Effectivement, le framework cible est Net Core 3.1.
Le problème, maintenant, c'est qu'il refuse l'installation du FrameWork 4.8, car il est déjà installé.
Pourtant dans la liste des FrameWorks cibles, il n'y a que des Net Core, et pas moyen de lui en faire utiliser un autre.

Je pense que cela se décide au moment de la création de la solution.
Le type d'application Windows Form est annoncé pour créer une apllication .NET Window Form, qui donc n'accepterai que des FrameWork .Net...

J'ai un autre projet développé en Visual Studio 2005, qui a été converti pour Visual Studio 2019, et il propose tous les FrameWorks.
(Il tourne avec FrameWorf 4.7.2).
Je n'arrive pas à trouver dans les propriétés du projet où est indiqué le type d'application, sinon je pourrai peut-être le copier.

Merci.

Bon après des plombes de recherche avec Net Core il faut passer par:

Code:

---

1 2	using System.Data.Common;

---

Et les connexions se font par

Code:

---

1 2 3 4 5 6

DbProviderFactory   et   DbConnexion

---

Par contre, si quelqu'un a un peu d'exemple d'utilisation en français, je suis preneur.

Merci

Après moultes recherches, pour les extensions SQL, c'est dans Projet >> gérer les packages NuGets

Par contre pas moyen de trouver des tutos corrects sur

DbProviderFactory

et

DbConnexion

Dommage, cela me semblait des outils intéressants lorsqu'on cherche à se connecter à des serveurs différents (SQL Server, MY Sql et Access)

Citation:

---

Envoyé par HENRYC

Après moultes recherches, pour les extensions SQL, c'est dans Projet >> gérer les packages NuGets

Par contre pas moyen de trouver des tutos corrects sur

DbProviderFactory

et

DbConnexion

Dommage, cela me semblait des outils intéressants lorsqu'on cherche à se connecter à des serveurs différents (SQL Server, MY Sql et Access)

---

Salut à toi, j'ai l'impression déjà qu'avec .net tu es un peu perdu (et je ne vais pas te jeter la pierre, ça m'arrive aussi). Donc au cas où, s'il y a des informations dont tu ne disposes pas ... net framework a reçu sa dernière maj et normalement ça ne bougera plus. MS veut se concentrer sur .net core. Donc comme toi j'étais sur .Net core 3.1 et je n'ai pas réalisé ayant loupé l'information que .net 5 c'est la suite de .net core 3.1, ils ont passé sur le 4 et levé le core.
Donc déjà si ça a dégrossi un peu ta manière de voir les choses, çe me fera plaisir sinon ça veut dire que mon post est inutile et tant pis pour moi :mrgreen:.

.net framework est dépendant de l'environnement, je ne suis pas développeur pro mais autodidacte dont peut être que je n'ai pas les mots pour, mais disons que si tu veux faire un stand alone ce n'est pas .net Framework mais .net Core qu'il faut. Le premier aura nécessairement besoin que l'utilisateur installe un paquet MS. Le second (donc .net core) peut être créé avec toutes les dll et donc ne plus dépendre, visual studio se charge de faire le nécessaire. Si je me souviens bien dans publication en fait tu peux régler ça ... La différence va être niveau taille et fichiers, une version dépendante de l'environnement va faire 30Mo par exemple, un stand alone va en faire 100 pas de quoi fouetter un chat vu les capacités de stockage qu'on a actuellement. Par contre on peut utiliser un projet .net Framework dans un .net Core (pas l'inverse de mémoire), dans ta solution tu peux donc importer un autre projet, et quand tu vas ajouter ta référence au lieu de chercher une dll tu peux directement aller dans projets partagés (si ma mémoire est bonne).

Donc quand tu crées ton projet, tu as le choix entre .net Framework, .net core et là en fait quand tu as choisi .net core tu pourras remarquer que dans les propriétés de ton projet tu peux switcher entre .net 5 et .net core... mais donc pas entre .net core et .net framework. Logique après coup.

J'ai mis la main sur un vieux programme que j'avais laissé en plan, qui était sur du SQLite, j'ai aussi fait avec du Access mais jamais avec MYSQL.

Je t'avoue qu'à l'époque ça devait pas être optimisé, mais ça tournait (exemple sur la boucle qui n'est pas respectueuse, donc sur une base online faire attention )

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

// Vérification de l'existance du fichier if (!File.Exists(Settings.Default.DataBase_Path)) { this.Dispose(); throw new IOException("Base de donnée inaccessible"); }   // Connexion try { SQLiteConn = new SQLiteConnection($"Data Source={Settings.Default.DataBase_Path};Version=3"); SQLiteConn.Open();   while (SQLiteConn.State == ConnectionState.Closed) { Debug.WriteLine("waiting"); }   Debug.WriteLine($"SQlite_Test, connexion à '{SQLiteConn.DataSource}': {SQLiteConn.State}"); } catch (SQLiteException sqlEXC) { Debug.WriteLine(sqlEXC.Message); this.Dispose(); throw new Exception("Erreur SQlite"); }

---

De mémoire aussi tu dois avoir des tutos sur le site aussi.



Je t'invite au fait à regarder du côté des requêtes paramétrées si tu ne connais pas encore.

salut Daerlnaxe,

Désolé pour le retard, j'avais zappé cette discussion car finalement j'ai préféré revenir au FrameWork 4.7.
Je reviendrai sur .net core beaucoup plus tard quand j'aurai beaucoup de temps à y consacrer.
Nul doute que je relirai ton post attentivement à ce moment là.

Merci.