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.