Discussion :

[monsrhf]

Bonjour,
Je suis un d�butant sur C++. Je travail sur le d�veloppement d'une application informatique en C++, et je suis sur l'�tape o� je dois �crire du code qui charge ou appelle ou interroge ma base de donn�e. Sauf que je ne suis pas habitu� � ce genre de probl�me, c'est la premi�re fois en faite ! Je ne trouve pas de ressource qui traite cette probl�matique.
Ma question est quels sont les outils et techniques qui nous permettent de charger les objets de la base de donn�es � partir d'un code C++ et s'il y a des tutoriels ou des ressources qui traitent cette probl�matique ?
Merci !

[foetus]

Pour le bas niveau, voici 2 termes � chercher sur

1. Domain model (<- lien wiki en)
2. Mapping objet-relationnel (<- lien wiki fr)

C'est un d�bat tr�s complexe avec des guerres de tranch�es , justement parce que ORM est consid�r� comme de la mauvaise POO.

[monsrhf]

Pour bien m'expliquer : mon probl�me c'est comment g�rer ma base de donn�e qui est sous access 2013 avec C++? et comment utiliser les requ�tes qui sont dans ma base de donn�e ?
c'est � dire dans le corps de mon programme y-t-il des biblioth�ques avec des fonctions bien d�finis que je dois utiliser?
merci !

[bacelar]

mon probl�me c'est comment g�rer ma base de donn�e qui est sous access 2013 avec C++?

Alors vous prenez le probl�me � l'envers.
Si vous commencez par C++ pour descendre jusqu'� ACCESS, vous vous prenez le nombre colossale de librairies, frameworks et autre middlewares accessibles depuis le C++ juste pour trouver les quelques composants plus ou moins compatible avec cette antiquit� d'ACCESS.
En prenant le probl�me dans l'autre sens, depuis ACCESS, vous avez quelques composants/Framework utilisable avec ACCESS (l'ouverture, pour ACCESS, ce n'est pas une qualit� cardinale, LOL).
Si vous ne voulez pas �tre soud� � ACCESS jusqu'� la fin des temps, vous pouvez tenter de mettre un middleware entre ACCESS et votre application, comme un de bas niveau ODBC (beurk!) ou avec un niveau d'abstraction de plus au niveau comme un ORM compatible comme Entity Framework ou qui s'appuie sur un autre middleware de plus bas niveau (comme ODBC) => middlewares multi-couche.

Si vous voulez y aller comme un bourrin sans �valuer les diff�rentes approches, je vois 2 approches de golgoth :
- #import sur les composants COM d'acc�s � ACCESS, https://msdn.microsoft.com/fr-fr/lib...or=-2147217396
- faire du C++/CLI pour acc�der au Framework .NET bas niveau d'acc�s aux donn�es ADO.NET (voir aussi les Framework de plus haut niveau).

[monsrhf]

Si vous ne voulez pas �tre soud� � ACCESS jusqu'� la fin des temps, vous pouvez tenter de mettre un middleware entre ACCESS et votre application, comme un de bas niveau ODBC (beurk!) ou avec un niveau d'abstraction de plus au niveau comme un ORM compatible comme Entity Framework ou qui s'appuie sur un autre middleware de plus bas niveau (comme ODBC) => middlewares multi-couche.

je sais tr�s bien qu'il y a chemin autre d'�tre soud� a access jusqu'� la fin des temps mais � mon niveau je veux commencer par un truc simple pour voir le processus comment il fonctionne et apr�s bien sur pour voir autrement je vais passer par un middlewares. Alors pour commencer est ce que DAO par exemple est applicable dans mon cas.
Merci !

[bacelar]

J'ai pas d'Access 2013 sous la main.
V�rifiez dans la base de registre les ProgID qui ont �t� fourr�s par ACCESS 2013, s'il en fournit encore.
J'avais lu ACCESS 2003, pas ACCESS 2013, je suis pas s�r que M$ continue � fournir des composants COM directement dans ACCESS.

EDIT : ha ba si, vu qu'il y a toujours un support VBA dans Office.
Vous aurez largement plus de documentation sur le "mod�le objet" du bidule dans les sources VBA qu'en C++.

Alors pour commencer est ce que DAO par exemple est applicable dans mon cas.

Oui.
Mais vous parlez des classes type CDaoDatabase des MFC ou les classes g�n�r�s par "#import "DAOxxx.dll" ?

Montrez votre code utilisant DAO et le probl�me concret.