Bonjour les gens.
Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
C++ (sous linux).
Quelqu'un dans l'assistance aurait-il ça sous la main ?
Un lien, une doc, je suis preneur...

znort wrote on 06/05/2008 20:01:
> Bonjour les gens.
> Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
> C++ (sous linux).

MS SQL de Mr MS ? le seul moyen "officiel" est de jouer au clicodrome
dans Visual Studio 2008 Architect Pro. etc pour faire ça !...

factuellement, MS donne déjà peu d'info pour le faire à la main depuis
un système windows de base (Win Svr 2008) alors depuis linux ?!!

si vous trouvez des infos, merci de refaire un post (même HC) pour
résumer votre solution.

Sylvain.

In article <48209d12$0$897$ba4acef3@news.orange.fr>,
znort <znortznort@pasdespammnononmerci.free.fr> wrote:
>Bonjour les gens.
>Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
>C++ (sous linux).
>Quelqu'un dans l'assistance aurait-il ça sous la main ?
>Un lien, une doc, je suis preneur...

Le plus simple, c'est sans doute de faire un proxy sur la machine sous
windows, et de se connecter dessus depuis le nunux.

(j'ai deja fait un montage similaire avec du perl, avec DBI, DBD::Proxy,
et Win32::ODBC, et ca marchait raisonnablement bien).

Bonne chance pour faire l'equivalent en C++...

Sylvain SF a écrit :
> factuellement, MS donne déjà peu d'info pour le faire à la main depuis
> un système windows de base (Win Svr 2008) alors depuis linux ?!!

Une recherche dans Google permet de facilement trouver une
bibliothèque C++ qui permet d'accéder à MSSQL depuis Unix ODBC.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Mickaël Wolff wrote on 07/05/2008 01:51:
> Sylvain SF a écrit :
>> factuellement, MS donne déjà peu d'info pour le faire à la main depuis
>> un système windows de base (Win Svr 2008) alors depuis linux ?!!
>
> Une recherche dans Google permet de facilement trouver une
> bibliothèque C++ qui permet d'accéder à MSSQL depuis Unix ODBC.

c'est une évidence. reste que MS a inclut des tonnes de trucs proprio
(non ISO, non X/Open) dans son layer ODBC et qu'un lien ODBC - ODBC
basé sur le standard seul ne donnera pas vraiment toute la mesure
d'un serveur 2005.

Sylvain.

znort wrote on 06/05/2008 20:01:
> Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
> C++ (sous linux).
> Un lien, une doc, je suis preneur...

un lien qui mérite peut être d'être cascadé:
<http://www.sommarskog.se/mssql/unix.html>

Sylvain.

Mickaël Wolff a écrit :

> Une recherche dans Google permet de facilement trouver une
> bibliothèque C++ qui permet d'accéder à MSSQL depuis Unix ODBC.

Franchement, si une recherche permettait de trouver "facilement", je ne
serai pas en train
de poser la question...

Sylvain SF a écrit :
> znort wrote on 06/05/2008 20:01:
>> Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
>> C++ (sous linux).
>> Un lien, une doc, je suis preneur...
>
> un lien qui mérite peut être d'être cascadé:
> <http://www.sommarskog.se/mssql/unix.html>

Merci pour le lien...

znort a écrit :
> Mickaël Wolff a écrit :
>
>> Une recherche dans Google permet de facilement trouver une
>> bibliothèque C++ qui permet d'accéder à MSSQL depuis Unix ODBC.
>
> Franchement, si une recherche permettait de trouver "facilement", je ne
> serai pas en train
> de poser la question...

1 minute pour trouver FreeDTS et 30 secondes de plus pour trouver le
wrapper TDS++:
http://www.freetds.org/
http://www.raketforskning.com/tdsplusplus.html

Et Wikipedia en prime:
http://en.wikipedia.org/wiki/FreeTDS

C'est en version 0.82 et c'est distribué sous LGPL. A évaluer.

--
Michael

znort wrote:
> Mickaël Wolff a écrit :
>
>> Une recherche dans Google permet de facilement trouver une
>> bibliothèque C++ qui permet d'accéder à MSSQL depuis Unix ODBC.
>
> Franchement, si une recherche permettait de trouver "facilement", je ne
> serai pas en train
> de poser la question...

Justement apprends à chercher.
En anglais , évidemment : 0.26 secondes pour trouver.
Il y a de ces quiches...

marco a écrit :
> znort wrote:
>> Mickaël Wolff a écrit :
>>
>>> Une recherche dans Google permet de facilement trouver une
>>> bibliothèque C++ qui permet d'accéder à MSSQL depuis Unix ODBC.
>>
>> Franchement, si une recherche permettait de trouver "facilement", je
>> ne serai pas en train
>> de poser la question...
>
> Justement apprends à chercher.
> En anglais , évidemment : 0.26 secondes pour trouver.
> Il y a de ces quiches...

Ouah, respect, t'es super fort toi... t'as tapé quoi pour trouver en
0.26 secondes ?
Pauvre type...

marco wrote on 07/05/2008 16:35:
>
> Justement apprends à chercher.
> En anglais , évidemment : 0.26 secondes pour trouver.
> Il y a de ces quiches...

affligeant !!!!!!!!!!!!!!!!

tu considères qu'un ng ne sert qu'à se balancer des certitudes
inutiles ? tu n'as pas imaginé que l'on pouvait justement y
fournir des conseils pour chercher ?

ta bécane et / ou connexion est lente, moi il me faut 0.15 sec.
pour obtenir 313000 réponses à "q=mssql+unix+sample"; tu estimes
pour autant que ces 0.15, ou 0.26, sec. fournissent l'exemple code
de connexion à MS SQL en C++ demandé ? ou considères-tu que la
question n'a pas à être traitée du moment que l'on sait obtenir
une page quelconque de liens tous aussi peu pertinents ?

des quiches, sur qu'il y en a sur usenet ! les donneurs de leçons
incapables de donner le moindre conseil y sont en bonne place.

Sylvain.

znort a écrit :
> Franchement, si une recherche permettait de trouver "facilement", je ne
> serai pas en train
> de poser la question...

Alors il faut en parler. Quand je sollicite un forum, c'est pour faire
avancer mes recherches. Pour que ça avance, je montre ce que j'ai fais,
quelles furent mes recherches, et j'essaye d'expliquer en quoi telle ou
telle solution n'apporte pas de réponse satisfaisante. Ça évite à tout
le monde de perdre du temps.

Je t'aurais bien demandé de mieux exposer tes recherches, mais étant
donné que tu fut insultant dans un message, je ne pense pas que qui que
ce soit ne te réponde plus avant.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Mickaël Wolff a écrit :

> Je t'aurais bien demandé de mieux exposer tes recherches, mais étant
> donné que tu fut insultant dans un message, je ne pense pas que qui que
> ce soit ne te réponde plus avant.

!!!
Tu es bien la personne qui m'a traité de quiche non ?
Si ça, ça n'est pas insultant....

znort a écrit :
> Mickaël Wolff a écrit :
>>
> Tu es bien la personne qui m'a traité de quiche non ?

Non, c'est pas lui.

Ces posts sont très émotionnels, je propose l'arrêt des hostilités.

--
Michael

znort a écrit :

> Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
> C++ (sous linux).

1.La connexion nécessite l'installation de FreeTDS
Installation et configuration ici :
http://fr.gentoo-wiki.com/HOWTO_Acce...shell_par_ODBC

2.Télécharger otlv4.h : http://otl.sourceforge.net/

3.Et pis c'est tout !

Un exemple, plutôt complexe, il est vrai )) d'utilisation :
création d'une table alphabet et correspondance ASCII

#include <iostream>
using namespace std;
#define OTL_ODBC //MS SQL 7.0/ 2000
#include "otlv4.h" // OTL header file

otl_connect db; // déclare la Bdd


int main()
{
otl_connect:tl_initialize(); // initialise l'environment ODBC
try{
db.rlogon("UID=utilisateur;PWD=pass;DSN=le_nom_dan s_odbc.ini"); //
connection à ODBC
otl_cursor::direct_exec (db,"drop table
test",otl_exception::disabled); // suppression de la table
otl_cursor::direct_exec (db,"create table test(val int, ascii
text)"); // création
//ajout d'enregistrements
otl_stream o(1,"insert into test values(:val<int>,:ascii<char[2]>)",db);
for(int i=65;i<=90;++i){char j = i;o<<i<<j;}
}

catch(otl_exception& p){ // gestion des messages d'erreur
cout<<"ERREUR !\n";
cout<<"message : "<<p.msg<<endl; // print out error message
cout<<"requete : " <<p.stm_text<<endl; // print out SQL that caused
the error
cout<<"etat : "<<p.sqlstate<<endl; // print out SQLSTATE message
cout<<"variable :"<<p.var_info<<endl; // print out the variable that
caused the error
}

db.logoff(); // déconnexion
return 0;
}

znort wrote on 15/05/2008 17:31:
>
> 1.La connexion nécessite l'installation de FreeTDS
>
> #include "otlv4.h" // OTL header file
>
> otl_connect db; // déclare la Bdd

la _connexion_ plutôt que la base.

> otl_connect:tl_initialize();
> db.rlogon("UID=utilisateur;PWD=pass;DSN=le_nom_dan s_odbc.ini");

certes comme "exemple SIMPLE de connexion", c'est simple !

> otl_cursor::direct_exec (db,
> "drop table test", otl_exception::disabled);

c'est là où j'aime moins les différentes librairies évaluées.
bcp d'entre elles ne proposent que des "classes de transport"
entre les requetes SQL et le serveur, ces classes ne virtualisent
pas les concepts objets inhérents à une base, ni même ne rendent
compte de ses éléments.

ici, je préfère une syntaxe comme:

Table& table = db.get("t_table_name"); // ou opérateur(const char*)

puis: "table.drop();"

> otl_cursor::direct_exec (db,
> "create table test(val int, ascii text)");

<sql>
un "char[2]" plutôt que "text" ?
</sql>

la simple execution de la requete SQL est ici aussi au dépend d'une
approche plus fine, par exemple (sauf à imaginer une famille de classe
d'exception dérivée de otl_exception) on ne saura pas en cas d'erreur
si l'utilisateur n'a pas de droit CREATE ou si la structure de la table
est invalide.

je n'ai jamais rien vu pouvant ressembler à:

<non compilable>

Table& test = db.create("t_test");
test.define(
arrayOfColumns<?>(
{ 'val', <int> [, modifiers tels index,primary key, ...] },
{ 'ascii', <char[2]> }
));

</non compilable>

> otl_stream o(1,"insert into test values(:val<int>,:ascii<char[2]>)",db);
> for (int i=65;i<=90;++i) o << i << (char) i;

j'imagine qu'un compteur interne mémorise le nb d'args injectés et
transmet la requete INSERT lorsque que tous sont définis.

la commande parait donc traiter de l'insertion ligne à ligne, or
- MS SQL ne supporte pas l'insertion simultanée de plusieurs lignes
mais d'autres le font, la charge de transfert et de traitement
sur le serveur sera bien plus lourde que possible pour ceux-ci.
- aucun rollback ne semble pouvoir annuler l'insertion des lignes
si le process échoue au milieu de la boucle (pas de garantie
d'intégrité de la table par manque d'atomicité).


ces remarques ne traitent pas de la demande initiale d'une API
"simple"; dans le cadre d'un "wrapper" SQL je m'étonne tout de
même du peu d'offre "orienté objet" apparement disponible; tous
les modèles que j'ai pu voir présupposent une bonne connaissance
de SQL puisque les requetes doivent être construite à la main.

Sylvain.

On Thu, 15 May 2008 22:06:57 +0200, "Sylvain SF" :

>c'est là où j'aime moins les différentes librairies évaluées.
>bcp d'entre elles ne proposent que des "classes de transport"
>entre les requetes SQL et le serveur, ces classes ne virtualisent
>pas les concepts objets inhérents à une base, ni même ne rendent
>compte de ses éléments.

SQL est un langage de programmation, assez complexe.
Il me semble que le besoin de l'OP est le besoin typique : obtenir un
interpréteur pour ce langage, dans un contexte précis (client en C++
sous Linux, serveur Microsoft SQL sous Windows).

Créer une API en C++, c'est recréer ce langage complexe. Non seulement
ce serait un travail dingue, mais en plus, ça obligerait l'utilisateur
à apprendre un nouveau "langage" (i.e. la documentation de cette API),
juste pour ce cas précis, alors qu'il connaît déjà SQL.

À la rigueur, on peut toujours créer une bibliothèque capable, soit de
créer des requêtes SQL simples (pour les envoyer vers la bibliothèque
"client SQL"), soit d'aider à la création de requêtes, et
éventuellement de rajouter la notion de typage C++ sur les valeurs,
mais ce sera alors une bibliothèque totalement différente,
raisonnablement indépendante du serveur SQL utilisé.

Fabien LE LEZ wrote on 16/05/2008 00:32:
>
> SQL est un langage de programmation, assez complexe.

tout à fait.

> Il me semble que le besoin de l'OP est le besoin typique : obtenir un
> interpréteur pour ce langage, dans un contexte précis.

"interpréteur" ?

son besoin est "minimaliste" plus que typique (ou donne moi les stats)
et se résume à un "transporteur" de requêtes SQL.

> Créer une API en C++, c'est recréer ce langage complexe. Non seulement
> ce serait un travail dingue, mais en plus, ça obligerait l'utilisateur
> à apprendre un nouveau "langage" (i.e. la documentation de cette API),
> juste pour ce cas précis, alors qu'il connaît déjà SQL.

je ne pose pas qu'apprendre une API (et a fortiori une API métier)
soit pénible ou difficile (même si j'ai bien lu que certains "lecteurs
passent trop de temps à buter" sur toute nouveauté).

le programmeur C++ est de facto initié utiliser des concepts C++ pour
formuler ce qui cherche à faire (coder une opération comme écrire une
requête) et exploiter ses résultats.

écrire la requête elle-même n'est qu'une toute petite partie de
l'utilisation d'une base; faire des insertions propre (donc atomique,
avec rollback possible, ...) et exploiter des résultats (avec tous
les problèmes de conversion de types, de binding et de cache) est
autrement plus sensible, c'est à dire très impactant sur ce qui sera
possible de réaliser et sur les performances du traitement (je ne parle
pas d'une table de 100 lignes).

ces points là ne sont pas couvert - à ma connaissance - par une API C++,
certaines utilisent astucieusement des opérateurs pour construire une
clause where - mais ce n'est pas l'essentiel puisqu'elles ignorent tout
des jointures multiples, d'autres définissent de beaux templates pour
dé-binder les données en type utilisateur - mais après avoir tout
récupéré dans des std::string - avec des perfs loin d'être bonnes
sur des tables principalement binaires (champs entier).

une réponse possible à l'absence de lib. avancée est la préférence
des administrateurs SQL à travailler directement avec une console
SQL plutôt que de passer par un encodage C++, ceci est vrai pour
des requêtes très spécialisées et toujours différentes; pour de
nombreux usages courants, un GUI html ou VB et un layer PHP, ODBC
ou autre (4D est surement le moins pire) est souvent utilisé.


> À la rigueur, on peut toujours créer une bibliothèque capable, soit de
> créer des requêtes SQL simples (pour les envoyer vers la bibliothèque
> "client SQL"), soit d'aider à la création de requêtes, et
> éventuellement de rajouter la notion de typage C++ sur les valeurs,
> mais ce sera alors une bibliothèque totalement différente,
> raisonnablement indépendante du serveur SQL utilisé.

le langage SQL étant normalisé, il s'agirait bien sur de disposer
d'une lib. efficiente *et* indépendante du serveur.

Sylvain.

On Fri, 16 May 2008 01:05:52 +0200, "Sylvain SF"
<sylvain@boiteaspam.info>:

>> Il me semble que le besoin de l'OP est le besoin typique : obtenir un
>> interpréteur pour ce langage, dans un contexte précis.
>
>"interpréteur" ?

Oui, désolé, je me suis mal exprimé : il voulait un *accès* à
l'interpréteur SQL.

>je ne pose pas qu'apprendre une API (et a fortiori une API métier)
>soit pénible ou difficile

Le but est de faire la même chose que ce que permet SQL, mais avec une
API différente. Il n'y a aucune raison de penser que cette API sera
plus simple que SQL lui-même, qui est déjà passablement complexe.

Si un programmeur découvre la notion de base de données avec cette
API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base
de données via le langage SQL, en PHP par exemple), alors, pourquoi
pas.

Par contre, si un programmeur a déjà une certaine expérience avec SQL,
il va falloir de sacrés bons arguments pour le convaincre d'apprendre
un nouveau "langage" (ton API) pour faire sensiblement la même chose.



>le langage SQL étant normalisé, il s'agirait bien sur de disposer
>d'une lib. efficiente *et* indépendante du serveur.

Nous sommes donc d'accord : l'OP cherchait une bibliothèque de
connexion au serveur Microsoft, et il l'a trouvée ; il pourrait
utiliser, en complément, une telle bibliothèque "adaptatrice".

Sylvain SF a écrit :
> Fabien LE LEZ wrote on 16/05/2008 00:32:
>> SQL est un langage de programmation, assez complexe.
>
> tout à fait.

Pourtant SQL a été conçu pour être proche du langage humain. Comme quoi ...

>> Créer une API en C++, c'est recréer ce langage complexe. Non seulement
>> ce serait un travail dingue, mais en plus, ça obligerait l'utilisateur
>> à apprendre un nouveau "langage" (i.e. la documentation de cette API),
>> juste pour ce cas précis, alors qu'il connaît déjà SQL.

Avec un système à la Boost.Spirit l'expression pourrait largement
ressembler au SQL (ou même en partie au OQL). Cela amortirait la courbe
d'apprentissage. A voir l'intérêt d'une telle construction si c'est plus
rapide de l'écrire dans une string (typiquement, on teste dans une
console avant et puis copier/coller dans le code).

> ces points là ne sont pas couvert - à ma connaissance - par une API C++,
> certaines utilisent astucieusement des opérateurs pour construire une
> clause where - mais ce n'est pas l'essentiel puisqu'elles ignorent tout
> des jointures multiples, d'autres définissent de beaux templates pour
> dé-binder les données en type utilisateur - mais après avoir tout
> récupéré dans des std::string - avec des perfs loin d'être bonnes
> sur des tables principalement binaires (champs entier).

Est ce que les données transitent en binaires entre le client et la BDD ?

>> À la rigueur, on peut toujours créer une bibliothèque capable, soit de
>> créer des requêtes SQL simples (pour les envoyer vers la bibliothèque
>> "client SQL"), soit d'aider à la création de requêtes, et
>> éventuellement de rajouter la notion de typage C++ sur les valeurs,
>> mais ce sera alors une bibliothèque totalement différente,
>> raisonnablement indépendante du serveur SQL utilisé.
>
> le langage SQL étant normalisé, il s'agirait bien sur de disposer
> d'une lib. efficiente *et* indépendante du serveur.

Ce qui implique de repasser par des strings pour exprimer les requêtes
en SQL, donc le gain en vitesse est loin d'être acquis.

Michael

In article <sqdp2413j9083g87fu8cut75sb2v217481@4ax.com>,
Fabien LE LEZ <usenet15@x.edulang.com> wrote:
>SQL est un langage de programmation, assez complexe.

Non, c'est un langage informatique. Je ne l'eleverai pas a la qualite
de `langage de programmation'. Il y a des extensions (procedures stockees
et tutti-quanti) qui en font un vrai langage de programmation, mais je
ne pense pas qu'il soit Turing-complet, par exemple...

A la base, sql, ce n'est jamais qu'un formalisme un peu bizarre pour
representer la theorie des ensembles (ordonnes)...

On May 16, 2:15 am, Fabien LE LEZ <grams...@gramster.com> wrote:
> On Fri, 16 May 2008 01:05:52 +0200, "Sylvain SF"
> <sylv...@boiteaspam.info>:

[...]
> >je ne pose pas qu'apprendre une API (et a fortiori une API métier)
> >soit pénible ou difficile

> Le but est de faire la même chose que ce que permet SQL, mais avec une
> API différente. Il n'y a aucune raison de penser que cette API sera
> plus simple que SQL lui-même, qui est déjà passablement complexe.

> Si un programmeur découvre la notion de base de données avec cette
> API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base
> de données via le langage SQL, en PHP par exemple), alors, pourquoi
> pas.

> Par contre, si un programmeur a déjà une certaine expérience avec SQL,
> il va falloir de sacrés bons arguments pour le convaincre d'apprendre
> un nouveau "langage" (ton API) pour faire sensiblement la même chose.

Je comprends un peu le point de vue de Sylvain. La bibliothèque
OTL dont parle znort traite le SQL comme un espèce
d'entrées/sorties. Ce qui correspond effectivement à la réalité
physique, mais d'un certain côté, on aimerait pouvoir définir
une classe ou une struct qui correspond soit à une ligne dans un
tableau, soit à une suite de colonnes, mais avec un comportement
en plus (pourquoi pas ?) et puis avoir des accès qui
ressemblent à l'utilisation d'un std::vector ou d'un std::map
(avec éventuellement une cause de where comme argument au
constructeur). L'idée, je crois, n'est pas d'exprimer le SQL
avec un autre API, mais plutôt de le présenter selon un modèle
objet plus habituel aux programmeurs C++.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Michael DOUBEZ wrote on 16/05/2008 09:44:
>
> Avec un système à la Boost.Spirit l'expression pourrait largement
> ressembler au SQL (ou même en partie au OQL). Cela amortirait la courbe
> d'apprentissage.

je ne connais pas assez Spirit pour savoir.
dans le même temps, je ne suis pas certain qu'une ressemblance
stricte entre les expressions C++ et la syntaxe SQL soit
nécessaire. le pré-requis est bien sur de connaitre et comprendre
la structure relationelle de ses infos, ensuite la manipulation
de ces relations pourrait être C++ pur.

> Est ce que les données transitent en binaires entre le client et la BDD ?

dans le cas d'une API directe oui, pour un layer ODBC (ou tout layer
avec son propre marshalling) c'est undéfini.

> Ce qui implique de repasser par des strings pour exprimer les requêtes
> en SQL, donc le gain en vitesse est loin d'être acquis.

une requête (la requête envoyée) est toujours une string; la réponse
est mixte, chaque ligne-réponse peut contenir du texte ou du binaire
selon la seule définition de la table.

l'objet "requete" n'est qu'un petit élément, les objets cursors
(parseurs de réponses) sont les éléments les plus sensibles pour
les gains ou pertes de perf.; des objets tables (connaissant
implicitement leurs colonnes - pour vérifier avant transmission
la validité d'une sélection - et leurs références externes - pour
ne pas avoir à taper explicitement les jointures - seraient des
aides à la création de requete.


@ Marc: SQL:2003 (ISO 9075:2003) est turing-complet.

Sylvain.

>> On May 16, 2:15 am, Fabien LE LEZ wrote:
>> Le but est de faire la même chose que ce que permet SQL, mais avec une
>> API différente. [...]

non, ce n'est pas le but.

>> Si un programmeur découvre la notion de base de données avec cette
>> API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base
>> de données via le langage SQL, en PHP par exemple), alors, pourquoi
>> pas.

un code PHP n'a *pas* d'autre choix aujourd'hui que d'utiliser
une syntaxe SQL pour ces requêtes - l'exploitation des résultats
de la requête (via 'mysql_result' ou 'mysql_fetch_array') n'est
pas dans le scope de SQL qui ne définit pas la représentation -
externe à la base - d'un cursor.

> James Kanze wrote on 16/05/2008 11:55:
> [...] L'idée, je crois, n'est pas d'exprimer le SQL
> avec un autre API, mais plutôt de le présenter selon un modèle
> objet plus habituel aux programmeurs C++.

merci.

Sylvain.