SQL et C++ (Tutoriel complet? )

Bonjour,

J'ai besoin d'utiliser une base de donnés pour un projet.
Je code ce projet en C++, sous linux et windows.
Je cherche donc une API afin de communiquer avec une base de donnée SQL.

Pour la base de données, je ne suis pas encore sur mais je pense que je vais m'orienter sur MySQL. (Petite base de données mais avec écriture en multithread et très rapide par moment).

J'ai utiliser pour un ancien projet JDBC et MySQL, donc qqc dans le genre pourrait etre utile.

Pour l'instant j'ai regarder un peu une API pour ODBC: http://libodbcxx.sourceforge.net/

mais je ne trouve pas de tutoriel complet..., je ne suis pas sur d'avoir installer les bon drivers, je n'ai pas trouver d'exemple pour cette librairie?
Est-ce c'est peut etre plus facile d'utiliser directement la librairie pour mysql?
Que me conseillez vous car je suis un peu perdu.


Pour l'instant je veux tester sous linux comment ca marche donc j'ai fait les chose suivante:

- Installer MySQL (avec XAMPP)
- Installer le driver manager unixodbc (et aussi libiodbc2)
- Installer le driver MySQL (libmyodbc)
- Compiler l'API libodbcxx.

Mais je n'ai pas vraiment trouver de code pour tester ce genre de probleme,
je ne suis pas sur que le driver manager sache ou est le driver sql, ... ??

Merci pour votre aide !!!

Ce projet est il destiné a être commercialisé ?

A priori, tu n'as besoin que de MySQL : pourquoi veut installer apache, php ?

Je ne connais pas unixodbc. J'ai déjà utilisé par contre libdbi ( http://libdbi.sourceforge.net/ ) un layer d'abstraction en C (pour mysql, sqlite etc). Plus récemment j'ai utilisé SOCI ( http://soci.sourceforge.net/ ) qui fait la même chose mais est en C++. Pas mal du tout.
Ce n'était pas du ODBC. Généralement, il suffit juste d'installer libmysqlclient et les libs se chargent et/ou fournissent le reste.

Ca c'est dans le repo de sourceforge pour libodbc++ : un test pour mysql.cpp
http://libodbcxx.svn.sourceforge.net...pp?view=markup
Vers la ligne 500, c'est là que la sa se connecte à mysql.
La doc pour le DriverManager, notament getConnection:
http://libodbcxx.sourceforge.net/lib...anager.html#d0
C'est dans le DNS que tu indiques que tu veux utiliser mysql.

Au même endroit tu as http://libodbcxx.svn.sourceforge.net...pp?view=markup
dmtest.cpp liste les DSN et les drivers dispo

Bon réponse un peu tardive.

ODBC m'a l'air un peu compliqué pour l'utilisation de ma base de donnés (5 tables avec 3 type de requêtes).

je vais tester d'intégrer libdbi a mon projet (visiblement c'est facile sur linux),
mais peut etre un peu plus compliquer pour windows. As-tu essayé ?
(J'aimerais bien pouvoir compiler les dll en utilisant cmake)

SOCI a l'air sympa mais peut être moins utiliser donc moins de support je pense. En plus, les blob data ne sont pas supportés avec MySQL. (D'apres la doc, est-ce que tu as testé?)

le projet devrais etre commercialisé (mais on n'est pas encore sur de la licences)
Pour l'instant j'ai utiliser que des librairies LGPL donc pas de probleme.
Mais je suis entrain de me poser une question: Si j'utilise MySQL comme base de données (GPL) mais que je l'install a part. Et que je me connecte avec Libdbi (LGPL) a la BD.
Est-ce qu'il y a un problème pour distribué mon code en version commerciale?

Les blobs ne sont pas supportés pour le mysql backend de SOCI. Je n'ai pas essayé de toute façon, mais comme tu l'as vu, c'est dans la doc. Cependant, je crois avoir vu je ne sais où que c'est en cours de réalisation.
Les blobs sont supportés par le backend Postgre par contre.

Je n'utilise ça que sous linux. Dans la doc, il semble que SOCI soit utilisable sous Windows (ils fournissent des .sln) mais mysql n'est apparemment pas supporté pour Windows... (cf. doc)

Pour les histoires de GPL/LGPL, franchement, je n'en sais rien. Faudrait étudier ça :mrgreen:
Les utilisations que j'ai fait de tout ça n'étaient que dans le cadre du hobby

Je préfère de loin SOCI à libdbi, parce que son api est en "c++ moderne" (proche de la stl, utilisation de tuples, compatible avec boost etc). Et si vraiment on veut du très low level, on peut toujours choper un accès à l'api native de base (pour mysql, postgre etc). Et donc pour les blobs, y a moyen de gérer ça à la "main" dans le pire des cas.

Aussi, si tu as vraiment peu de tables et peu de requêtes, passer par SQLite peut être une solution envisageable... (via SOCI ou autre..)

merci pour les conseils!

du coup je suis en train de regarder pour postgreSQL car c'est LGPL donc il n'y a pas de problème pour un programme commercial.

pour SQLlite je peux pas car j'ai des accès SQL concurrent en écriture, ce qui peut etre un problème (selon la doc).

Merci encore.