Discussion :

[michel.di]

Bonjour,
Désolé pour le double post, j'ai utilisé le mauvais pseudo!
j'ai un petit problème:
je dois faire communiquer mon appli en C/C++ avec une base de données sous Oracle. j'ai pu voir sur le site un tuto http://vicenzo.developpez.com/tutoriels/c/ocilib

Est-ce le seul moyen? Est-on obligé d'installer des dll externes pour faire ceci ?

Merci d'avance pour votre aide

[Vincent Rogier]

Salut,

pour accéder à oracle, il te faut une API cliente.
Oracle fournit des API C (OCI) et C++ (OCCI) pour accéder à des bases de données Oracle.

Ensuite, il existe des wrappers autour de OCI (qui est une API tres complexe) comme OCILIB. Les frameworks comme Qt implementent leurs drivers sur OCI.

OCCI est un mauvais choix car :
- tres tres buggé depuis sa création
- peu de compilateurs supportés (de plus peu de versions de ceci)

Il existe aussi 2 drivers commerciaux qui implémentent eux meme le protocole réseau d'Oracle (SQL*NET). Mais c'est pas donné et toujours risqué car Oracle ne documentant pas ce protocole, les futures compatibilités sont pas sures (mais bon...)

Donc, au final, tu es olbigé de te baser sur un client Oracle.

depuis 10g, Oraclle ayant compris que c'était galère d'installer en runtime un client oracle, de plusieurs centaines de Mégas , avec installateur et tout les tralala, fournit aussi un "Instant client". Ce client est réduit à 2-3 librairies partagées que tu peux redistribuer avec ton appli.

Donc, maintenant, à toi de choisir ton API utilisateur, OCILIB ou autre !

[michel.di]

merci beaucoup pour ta réponse très détaillée!
je vais voir avec ma boite si OCILIB leur convient!

merci encore

[Vincent Rogier]

- si tu codes nativement en C++ et que tu utilises à fond la STL, OTL peut être très intéressant (quoi que moins performant que OCILIB et beaucoup moins riche) et lui aussi en open source

- si tu codes en C ou en C++ mais que utiliser une API C t'es égal, OCILIB est le wrapper C le plus abouti, le plus riche et le plus mature.

Les autres wrappers/librairies C/C++ au dessus de OCI ne valent pas le coup (buggés, peu de support des fonctionnalités Oracle, non maintenues..).

Maintenant, si tu utilise un framework particuliers comme Qt ou autre, vois s'ils non pas leur propre driver...

Encore une fois, OCILIB est l'API qui supporte le plus de fonctionnalités Oracle... Ne serait-ce que la clause SQL "returning into", le full support des objets, des collections, l'unicode, le mulithreading by oracle, etc...

[Grulim]

Ca n'empêche pas l'installation de dll oracle, mais Pro*C (du C/C++ avec un préprocesseur sauce Oracle) permet de travailler avec une base Oracle, de manière simple et efficace.
De plus, ce n'est pas très compliqué à mettre en oeuvre.

[Vincent Rogier]

Effectivement, Pro*C est une option...

Ce qui me derange énormément, avec Pro*C :

- tu dois compiler un binaire pour chaque version d'oracle ( par exemple au taf, je compile 5 versions de mes applis PRO*C (8.17, 9.0; 9.2, 10.2, 11.1)... C'es chiant !
- tu dois avoir un client Oracle pour compiler (c'est con, mais c'est pratique de pouvoir compiler hors environnement oracle)
- créer une librairie en pro*c (statique / shared) et qui plus est en multithread (ca, c'est galère)
- faible support pour C99 (on est en 2009, hum...)
- peu adapté au multi-tiers (pour sur !)
- tu as déjà vu la tête d'un fichier *.c généré par PRO*C ? (c'est une plaie à débugger !)
- faible support Unicode (on est en 2009..hum..)
- gestion des curseurs archaïque et rigide
- couvre beaucoup moins de fonctionnalités Oracle que OCI

Pour moi, le seul intérêt de pro*c est la vérification du code SQL à la précompilation et c'est assez productif

Et si aucun des points cités ne gêne michel.di, qu'il envisage donc aussi PRO*C

J'utilise PRO*C quotidiennement au taf... C'est une bon produit mais je préfère mille fois faire du OCI...

[Grulim]

- tu dois compiler un binaire pour chaque version d'oracle ( par exemple au taf, je compile 5 versions de mes applis PRO*C (8.17, 9.0; 9.2, 10.2, 11.1)... C'es chiant !

La société pour laquelle j'ai développé en PRO*C a une approche assez Unix : on ne change pas quelque chose qui marche, donc dans la boite il n'y a qu'une version d'Oracle, une chance !

- tu dois avoir un client Oracle pour compiler (c'est con, mais c'est pratique de pouvoir compiler hors environnement oracle)

Il me semble qu'il existe un package ou il n'y a que les lib nécessaires

- faible support pour C99 (on est en 2009, hum...)

Sans parler des limitations inhérentes au préprocesseur qui limite les possibilités (#define vs enum, par exemple).

- tu as déjà vu la tête d'un fichier *.c généré par PRO*C ? (c'est une plaie à débugger !)

Je m'en suis sorti (IBM/AIX)

- faible support Unicode (on est en 2009..hum..)

Parles-tu des wchar_t ?

Pour moi, le seul intérêt de pro*c est la vérification du code SQL à la précompilation et c'est assez productif

Tout à fait d'accord !

[Vincent Rogier]

La société pour laquelle j'ai développé en PRO*C a une approche assez Unix : on ne change pas quelque chose qui marche, donc dans la boite il n'y a qu'une version d'Oracle, une chance !

Moi, j'ai pas le choix de la version Oracle (imposée) des clients, nous devons donc nous adaper (que ce soit sous windows ou unix)

Il me semble qu'il existe un package ou il n'y a que les lib nécessaires

Pour le runtime, pas pour la compilation !

[Grulim]

Pour le runtime, pas pour la compilation !

Je parle bien de la compilation, mais je confonds peut-être, ou bien c'était une solution maison (et sous Unix).

[ZashOne]

il y a aussi l odbc avec les recordsets MFC , c est pas le plus pro mais pour coder rapidement c est parfais

[michel.di]

pour finir on a utilisé une lib oci!
merci a tous pour voter aide
je marque le topic comme résolu

[Vincent Rogier]

laquelle ? (juste pour info...)

pour finir on a utilisé une lib oci!

[michel.di]

Je ne sais pas trop en fait car elle était présente dans les librairies d'Oracle et porte le nom de oci.h
Je vais essayer d'en savoir plus cet après-midi au boulot!

Je te remercie en tout cas pour m'avoir aidé à résoudre mes nombreux problèmes et pour le temps que tu m'as accordé!