connexion mssql

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.

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

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....

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

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_Acces_à_un_serveur_SQL_par_le_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 :o)) 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::otl_initialize(); // initialise l'environment ODBC
try{
db.rlogon("UID=utilisateur;PWD=pass;DSN=le_nom_dans_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 ie;i<;++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::otl_initialize();
db.rlogon("UID=utilisateur;PWD=pass;DSN=le_nom_dans_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 ie;i<;++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".

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