Discussion :

[Chebil2006]

Salut à tous;
j'ai réalisé des applications en vb6 avec BD en access et en sql. Il y'a quelque temps j'ai voulu migrer vers la plateforme DotNet et j'ai commencé à réecrire une application en C++/CLI selon l'architecture Client/Serveur (BD côté Serveur).
Je suis parvenu à faire la connexion aux BD et à manipuler les tables mais la seule solution que j'ai trouvé pour accéder aux champs d'une table est d'utiliser un array et d'accéder aux champs par leurs rang comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Chainesql = "SELECT DISTINCT [Categorie_Libelle] FROM [Table_Nomenclature_Taille]";
if
(xAdoAccess.SVR_Db_Article_Read(Nom_Utilisateur,Nom_Poste,Chainesql))
{
array<Object ^> ^row = gcnew array<Object ^>(xAdoAccess.MyDataReader->FieldCount);
for (int i=0;i<row->Length;i++)
{
  xAdoAccess.MyDataReader->Read();
  xAdoAccess.MyDataReader->GetValues(row);
  FrmCategorie_Libelle->Items->Add(row[0]);
}
}

Alors qu'en VB6, il suffit, pour accéder à un champs, de faire Nom_Table![Nom_Champs] qui me semble plus pratique et plus lisible.
En tout cas, sauf s'il y'a quelques choses qui m'échappe dans les techniques de C++/CLI, est ce qu'on peut dire que ce langage est non orienté vers BD surtout que même dans ce site respectueux et qui m'a vraiment poussé et aidé dans ma vie professionnelle (mille merci à tous les membres) j'ai pas trouvé beaucoup d'explication (soit tutoriels ou Faq) concernant C++/CLI et les BD.
Merci.

[tomlev]

Alors qu'en VB6, il suffit, pour accéder à un champs, de faire Nom_Table![Nom_Champs] qui me semble plus pratique et plus lisible.
En tout cas, sauf s'il y'a quelques choses qui m'échappe dans les techniques de C++/CLI, est ce qu'on peut dire que ce langage est non orienté vers BD surtout que même dans ce site respectueux et qui m'a vraiment poussé et aidé dans ma vie professionnelle (mille merci à tous les membres) j'ai pas trouvé beaucoup d'explication (soit tutoriels ou Faq) concernant C++/CLI et les BD.

Le principe est le même dans tous les langages .NET... Il faut passer par la propriété Item (en C# cette propriété est accessible via l'indexeur du type, je sais pas trop comment ça se passe en C++), ou alors utiliser les fonctions GetString, GetInt32, GetValue, etc
Tu peux essayer quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

object^ toto = reader->Item["toto"]

Ou comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

object^ toto = reader["toto"]

[Chebil2006]

Merci Tomlev pour votre réponse. en tout cas j'ai essayé la manière dont vous m'avez décrit et ça pas marché. Toutefois en essayant VB.Net, on peut y faire en mettant Datarow("Nom_Champs")
Je cherche bien des conseils afin de me plonger dans Vb.Net, surtout que je travaille beaucoup avec les BD et que j'ai des experiences avec VB6.
La question se pose tjs, est ce qu'il y'a quelques choses qui m'échappent ou que le C++/CLI (je sais pas si pour MFC c'est différent) a sacrifié la lisibilité pour la sécurité.
Merci à tous.

[tomlev]

Merci Tomlev pour votre réponse. en tout cas j'ai essayé la manière dont vous m'avez décrit et ça pas marché.

Tu as dû faire une erreur quelque part... je viens d'essayer pour en avoir le coeur net, et le code suivant fonctionne sans problème :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	DbDataReader^ reader = cmd->ExecuteReader();
	while(reader->Read())
	{
		Console::WriteLine("{0}. {1}", reader["ID"], reader["LIB"]);
	}

[Chebil2006]

Je veux l'essayé après retour de travail, ça sera gentil de votre part de me dire quel type d'application C++ vous avez utilisé (CLI, MFC, Application WinForms....).
Merci infinnement.

[tomlev]

Je veux l'essayé après retour de travail, ça sera gentil de votre part de me dire quel type d'application C++ vous avez utilisé (CLI, MFC, Application WinForms....).
Merci infinnement.

Une appli console (mais ça n'a aucune importance...)

Par contre, MFC ça n'a rien à voir, ce n'est pas du C++/CLI mais du C++ standard (enfin, pour autant qu'on puisse considérer le C++ Microsoft comme "standard" , mais je n'entrerai pas dans ce débat...)

[Chebil2006]

Tout d'abord permettez moi de te remercier infiniment pour l'aide que tu m'as apporté. Mille merci.
J'ai essayé le code que tu m'as envoyé, et c'est après quelques essaies que j'ai découvrit que tu as utilisé l'espace de noms System:ata::Common;
En effet, moi j'étais concentré sur l'OleDb puisque je crois que c'est plus puissant (au niveau sécurité, portabilité...). Le truque que tu m'as fournit n'as pas marché pour cet espace de noms. Alors en utilisant l'espace Common, est ce que à ton avis on peut continuer de profiter des points forts apportés par l'ADO.Net (c'est à dire est ce que l'espace common est partie de l'espace OleDb ou qu'il est juste un lien avec l'ancienne technologie).
Encore merci pour le temps que tu m'as alloué.

[Chebil2006]

Toutefois en régardant la msdn j'ai trouvé quelques choses:
L'espace de noms System.Data.Common contient des classes partagées par les fournisseurs de données .NET Framework.

Un fournisseur de données .NET Framework décrit une collection de classes utilisées pour accéder à une source de données, notamment une base de données, dans l'espace managé. Les fournisseurs pris en charge incluent le fournisseur de données .NET Framework pour ODBC, le fournisseur de données .NET Framework pour OLEDB, le fournisseur de données .NET Framework pour Oracle et le fournisseur de données .NET Framework pour SQL Server. Les classes dans System.Data.Common sont conçues pour permettre aux développeurs d'écrire du code ADO.NET qui fonctionnera sur tous les fournisseurs de données .NET Framework.

ce que j'ai compris c'est que l'espace OleDb, SqlClient ... sont inclus dans l'espace Common. Alors à la première d'idée ça peut répondre à ma question puisque cet espace (Common) sera plus vaste et, normallement, continue à profiter de toutes les techniques et nouveautés Ado.net, Est ce que j'ai raison.

[tomlev]

En effet, moi j'étais concentré sur l'OleDb puisque je crois que c'est plus puissant (au niveau sécurité, portabilité...).

Non, ce n'est ni plus puissant, ni plus sûr, ni plus portable... c'est juste plus vieux
Le provider OleDb n'existe que pour pouvoir continuer à utiliser des anciens fournisseurs de données non managés

Alors en utilisant l'espace Common, est ce que à ton avis on peut continuer de profiter des points forts apportés par l'ADO.Net (c'est à dire est ce que l'espace common est partie de l'espace OleDb ou qu'il est juste un lien avec l'ancienne technologie).

System.Data.Common est la couche d'abstraction d'ADO.NET. Toutes les classes des providers ADO.NET 2.0 (OleDbConnection, OleDbCommand, SqlConnection, SqlCommand, etc.) héritent des classes abstraites définies dans System.Data.Common. Donc en fait, c'est juste un moyen d'écrire du code générique, indépendant du provider concret ADO.NET utilisé. En pratique, les instances d'objets manipulées sont bien sûr des instances des types concrets d'un provider spécifique, mais en les manipulant via les classes de System.Data.Common tu peux faire abstraction du provider réel.
Plus d'infos à ce sujet dans ce tutoriel :
http://johannblais.developpez.com/tu...-donnees/#LIII

ce que j'ai compris c'est que l'espace OleDb, SqlClient ... sont inclus dans l'espace Common.

Non, il ne sont pas inclus dedans, mais comme je l'ai dit leurs classes héritent de celles de System.Data.Common

Alors à la première d'idée ça peut répondre à ma question puisque cet espace (Common) sera plus vaste et, normallement, continue à profiter de toutes les techniques et nouveautés Ado.net, Est ce que j'ai raison.

Oui

[Chebil2006]

J'apprécie vraiment ton aide, mille et mille merci. Tu m'as vraiment sauvé d'une galère (Je veux me plonger de nouveau dans le monde de C++).

[tomlev]

Si je peux me permettre un petit conseil : à moins que tu n'aies une raison particulière de vouloir utiliser C++/CLI (interop avec du code natif par exemple), c'est pas vraiment le langage le plus facile ni le plus pratique pour coder en .NET... VB.NET ou C# sont beaucoup plus adaptés, car conçus spécifiquement pour .NET (surtout C#). L'IDE est plus simple, il y a plus d'assistants, l'intellisense et l'auto-complétion marchent mieux, la syntaxe est moins lourde, les erreurs sont indiquées avant même la compilation... etc.

Enfin bon, c'est juste mon avis... après tu fais ce que tu veux, mais personnellement je trouve que coder en C++ de nos jours, c'est du masochisme

PS: n'oublie pas le tag si ça marche...

[Chebil2006]

Je veux prends ton conseil en considération. Toutefois, de temps en temps je veux rendre visite à la plage de C++, sans se plonger bien sûr je veux alors m'orienter vers C#, mais je compte bien sur ton aide si je tombe sur un problème dont je trouves pas de solution dans la faq ou les tutoriels.
Encore une fois mille merci et mille merci pour le conseil.