Une base de données multi-thread sous Windows pour du C++
17 réponses
Seb
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de
données vers une base proposant une API qui soit facilement "codable" en C++
(Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé
développer une DLL avec le "free command line" de Borland (là ça fonctionne)
et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre
d'architecture. Qu'en pensez-vous ?
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en
C++
(Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça
fonctionne)
et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
c'est ce prendre la tête pour pas grand chose.
utiliser ADO, et ensuite, choisir dans la galaxie des sgbds qui vont bien : de dBase qui est le 0 absolu à Oracle en passant par SqlServer, Access...
fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet en C++ Builder, et le recompiler, ça va prendre 10 fois moins de temps et ça marchera tout aussi bien, non ?
> "Seb" <nospam@yahoo.net> a écrit dans le message de
news:btlpnt$54g$1@s1.read.news.oleane.net...
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de
données vers une base proposant une API qui soit facilement "codable" en
C++
(Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé
développer une DLL avec le "free command line" de Borland (là ça
fonctionne)
et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre
d'architecture. Qu'en pensez-vous ?
c'est ce prendre la tête pour pas grand chose.
utiliser ADO, et ensuite, choisir dans la galaxie des sgbds qui vont bien :
de dBase qui est le 0 absolu à Oracle en passant par SqlServer, Access...
fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet en C++
Builder, et le recompiler, ça va prendre 10 fois moins de temps et ça
marchera tout aussi bien, non ?
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en
C++
(Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça
fonctionne)
et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
c'est ce prendre la tête pour pas grand chose.
utiliser ADO, et ensuite, choisir dans la galaxie des sgbds qui vont bien : de dBase qui est le 0 absolu à Oracle en passant par SqlServer, Access...
fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet en C++ Builder, et le recompiler, ça va prendre 10 fois moins de temps et ça marchera tout aussi bien, non ?
Seb
"Ambassadeur Kosh" a écrit dans le message news: btlrnk$o23$
"Seb" a écrit dans le message de
news:btlpnt$54g$
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
c'est ce prendre la tête pour pas grand chose.
utiliser ADO, et ensuite, choisir dans la galaxie des sgbds qui vont bien : de dBase qui est le 0 absolu à Oracle en passant par SqlServer, Access...
Pour le moment et du fait de l'existant je ne souhaite pas changer d'environnement (Borland C++ 5) . Je n'ai jamais fait d'ADO : esce facile ?
fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet en C++ Builder, et le recompiler, ça va prendre 10 fois moins de temps et ça marchera tout aussi bien, non ?
Niveau performances, esce aussi "kif kif" ?
"Ambassadeur Kosh" <yanapa@nospamnocry.fr> a écrit dans le message
news: btlrnk$o23$1@news-reader2.wanadoo.fr
"Seb" <nospam@yahoo.net> a écrit dans le message de
news:btlpnt$54g$1@s1.read.news.oleane.net...
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de
données vers une base proposant une API qui soit facilement
"codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé
développer une DLL avec le "free command line" de Borland (là ça
fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas
d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
c'est ce prendre la tête pour pas grand chose.
utiliser ADO, et ensuite, choisir dans la galaxie des sgbds qui vont
bien : de dBase qui est le 0 absolu à Oracle en passant par
SqlServer, Access...
Pour le moment et du fait de l'existant je ne souhaite pas changer
d'environnement (Borland C++ 5) . Je n'ai jamais fait d'ADO : esce facile ?
fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet
en C++ Builder, et le recompiler, ça va prendre 10 fois moins de
temps et ça marchera tout aussi bien, non ?
"Ambassadeur Kosh" a écrit dans le message news: btlrnk$o23$
"Seb" a écrit dans le message de
news:btlpnt$54g$
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
c'est ce prendre la tête pour pas grand chose.
utiliser ADO, et ensuite, choisir dans la galaxie des sgbds qui vont bien : de dBase qui est le 0 absolu à Oracle en passant par SqlServer, Access...
Pour le moment et du fait de l'existant je ne souhaite pas changer d'environnement (Borland C++ 5) . Je n'ai jamais fait d'ADO : esce facile ?
fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet en C++ Builder, et le recompiler, ça va prendre 10 fois moins de temps et ça marchera tout aussi bien, non ?
Niveau performances, esce aussi "kif kif" ?
Remi Thomas
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ? http://www.hwaci.com/sw/sqlite/
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de
données vers une base proposant une API qui soit facilement "codable"
en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé
développer une DLL avec le "free command line" de Borland (là ça
fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas
d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ?
http://www.hwaci.com/sw/sqlite/
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ? http://www.hwaci.com/sw/sqlite/
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Ambassadeur Kosh
> Pour le moment et du fait de l'existant je ne souhaite pas changer d'environnement (Borland C++ 5) . Je n'ai jamais fait d'ADO : esce facile
?
ben c'est la dll que tu vas essayer de fabriquer. c'est un ensemble d'objets "abstraits" pour agir sur ton SGBD. connection, transaction, tout ça... physiquement, c'est du COM. faut pas être allergique c'est tout...
sinon, niveau MultiThread, c'est la perfection. autre chose que les DAORecordset à deux balles des MFC.
> fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet > en C++ Builder, et le recompiler, ça va prendre 10 fois moins de > temps et ça marchera tout aussi bien, non ?
Niveau performances, esce aussi "kif kif" ?
un algo en Exp(N), c'est un algo en Exp(N). c'est pas un inline ou lea changé en move qui va en faire un algo N. bon, en clair, oui, c'est pareil, et le benefice est immense (evolution de la norme, VCL, outils...).
on est en 2004, c'est pas humain d'envoyer encore les ptits nenfants dans la mine écrire les pompes à message et faire du MFC-OWL hand class pissing.
> Pour le moment et du fait de l'existant je ne souhaite pas changer
d'environnement (Borland C++ 5) . Je n'ai jamais fait d'ADO : esce facile
?
ben c'est la dll que tu vas essayer de fabriquer. c'est un ensemble d'objets
"abstraits" pour agir sur ton SGBD. connection, transaction, tout ça...
physiquement, c'est du COM. faut pas être allergique c'est tout...
sinon, niveau MultiThread, c'est la perfection. autre chose que les
DAORecordset à deux balles des MFC.
> fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet
> en C++ Builder, et le recompiler, ça va prendre 10 fois moins de
> temps et ça marchera tout aussi bien, non ?
Niveau performances, esce aussi "kif kif" ?
un algo en Exp(N), c'est un algo en Exp(N). c'est pas un inline ou lea
changé en move qui va en faire un algo N.
bon, en clair, oui, c'est pareil, et le benefice est immense (evolution de
la norme, VCL, outils...).
on est en 2004, c'est pas humain d'envoyer encore les ptits nenfants dans la
mine écrire les pompes à message et faire du MFC-OWL hand class pissing.
> Pour le moment et du fait de l'existant je ne souhaite pas changer d'environnement (Borland C++ 5) . Je n'ai jamais fait d'ADO : esce facile
?
ben c'est la dll que tu vas essayer de fabriquer. c'est un ensemble d'objets "abstraits" pour agir sur ton SGBD. connection, transaction, tout ça... physiquement, c'est du COM. faut pas être allergique c'est tout...
sinon, niveau MultiThread, c'est la perfection. autre chose que les DAORecordset à deux balles des MFC.
> fabriquer une dll, oui si tu veux. mais franchement, ouvrir le projet > en C++ Builder, et le recompiler, ça va prendre 10 fois moins de > temps et ça marchera tout aussi bien, non ?
Niveau performances, esce aussi "kif kif" ?
un algo en Exp(N), c'est un algo en Exp(N). c'est pas un inline ou lea changé en move qui va en faire un algo N. bon, en clair, oui, c'est pareil, et le benefice est immense (evolution de la norme, VCL, outils...).
on est en 2004, c'est pas humain d'envoyer encore les ptits nenfants dans la mine écrire les pompes à message et faire du MFC-OWL hand class pissing.
Seb
"Remi Thomas" a écrit dans le message news: 3ffe81b7$0$17135$
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ? http://www.hwaci.com/sw/sqlite/
Rémi
Ce choix a l'air judicieux, l'as-tu déjà implémenté ? En survolant leur site j'ai vu 2 version : normale et "no-sync". C'est la seconde qui semble être efficace. Esce un choix encore meilleur ?
Sebastien
"Remi Thomas" <remi@xtware.com> a écrit dans le message news:
3ffe81b7$0$17135$626a54ce@news.free.fr
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de
données vers une base proposant une API qui soit facilement "codable"
en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé
développer une DLL avec le "free command line" de Borland (là ça
fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas
d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ?
http://www.hwaci.com/sw/sqlite/
Rémi
Ce choix a l'air judicieux, l'as-tu déjà implémenté ? En survolant leur site
j'ai vu 2 version : normale et "no-sync". C'est la seconde qui semble être
efficace. Esce un choix encore meilleur ?
"Remi Thomas" a écrit dans le message news: 3ffe81b7$0$17135$
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ? http://www.hwaci.com/sw/sqlite/
Rémi
Ce choix a l'air judicieux, l'as-tu déjà implémenté ? En survolant leur site j'ai vu 2 version : normale et "no-sync". C'est la seconde qui semble être efficace. Esce un choix encore meilleur ?
Sebastien
Ambassadeur Kosh
ah oui, j'oubliais.
du fait que c'est une couche qui sépare le quoi du comment, on interchange le format de la base de donnée sans toucher une seule ligne de code, l'appli n'a plus à bricoler à droite gauche dans des repertoires et tout et tout, on change la base de poste sans prise de tête sur les postes clients...
ADO est trés efficace. bien plus que ODBC en tout cas. le natif ne sert plus vraiment à grand chose. bien sur, si tu as un jour un reseau qui debite à 100*2.5Ghz, la, tu peux envisager d'améliorer de ce côté, mais tant que le frein à main reste tiré du côté reseau...
évidement, si tu choisis une implantation spécifique, ça va te couper du monde. ADO est interessant ne serait-ce que parceque tout le monde s'en sert. Crystal Reports par exemple, la plupart des composants grilles, etc...
voila voila, j'espere que ça va t'aider.
ah oui, j'oubliais.
du fait que c'est une couche qui sépare le quoi du comment, on interchange
le format de la base de donnée sans toucher une seule ligne de code, l'appli
n'a plus à bricoler à droite gauche dans des repertoires et tout et tout,
on change la base de poste sans prise de tête sur les postes clients...
ADO est trés efficace. bien plus que ODBC en tout cas. le natif ne sert plus
vraiment à grand chose. bien sur, si tu as un jour un reseau qui debite à
100*2.5Ghz, la, tu peux envisager d'améliorer de ce côté, mais tant que le
frein à main reste tiré du côté reseau...
évidement, si tu choisis une implantation spécifique, ça va te couper du
monde. ADO est interessant ne serait-ce que parceque tout le monde s'en
sert. Crystal Reports par exemple, la plupart des composants grilles, etc...
du fait que c'est une couche qui sépare le quoi du comment, on interchange le format de la base de donnée sans toucher une seule ligne de code, l'appli n'a plus à bricoler à droite gauche dans des repertoires et tout et tout, on change la base de poste sans prise de tête sur les postes clients...
ADO est trés efficace. bien plus que ODBC en tout cas. le natif ne sert plus vraiment à grand chose. bien sur, si tu as un jour un reseau qui debite à 100*2.5Ghz, la, tu peux envisager d'améliorer de ce côté, mais tant que le frein à main reste tiré du côté reseau...
évidement, si tu choisis une implantation spécifique, ça va te couper du monde. ADO est interessant ne serait-ce que parceque tout le monde s'en sert. Crystal Reports par exemple, la plupart des composants grilles, etc...
voila voila, j'espere que ça va t'aider.
Thierry
Bonjour,
Ambassadeur Kosh a écrit :
physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
-- "Cinq cents connards sur la ligne de départ, Cinq cents blaireaux sur leur moto Combien d'années encore ces crétins bariolés F'ront leur terrain de sport d'un continent entier."
Bonjour,
Ambassadeur Kosh a écrit :
physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
--
"Cinq cents connards sur la ligne de départ,
Cinq cents blaireaux sur leur moto
Combien d'années encore ces crétins bariolés
F'ront leur terrain de sport d'un continent entier."
physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
-- "Cinq cents connards sur la ligne de départ, Cinq cents blaireaux sur leur moto Combien d'années encore ces crétins bariolés F'ront leur terrain de sport d'un continent entier."
Thierry
Bonjour,
Ambassadeur Kosh a écrit :
physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
J'ai trouvé ADO bien plus facile a utiliser qu'ODBC.
-- "Cinq cents connards sur la ligne de départ, Cinq cents blaireaux sur leur moto Combien d'années encore ces crétins bariolés F'ront leur terrain de sport d'un continent entier."
Bonjour,
Ambassadeur Kosh a écrit :
physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
J'ai trouvé ADO bien plus facile a utiliser qu'ODBC.
--
"Cinq cents connards sur la ligne de départ,
Cinq cents blaireaux sur leur moto
Combien d'années encore ces crétins bariolés
F'ront leur terrain de sport d'un continent entier."
physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
J'ai trouvé ADO bien plus facile a utiliser qu'ODBC.
-- "Cinq cents connards sur la ligne de départ, Cinq cents blaireaux sur leur moto Combien d'années encore ces crétins bariolés F'ront leur terrain de sport d'un continent entier."
Remi Thomas
Seb wrote:
"Remi Thomas" a écrit dans le message news: 3ffe81b7$0$17135$
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ? http://www.hwaci.com/sw/sqlite/
Rémi
Ce choix a l'air judicieux, l'as-tu déjà implémenté ?
Oui, et fonctionne très bien. C'est le nouveau moteur de base de données par défaut dans PHP5 vu le changement de licence pour MySQL.
En survolant leur site j'ai vu 2 version : normale et "no-sync". C'est la
seconde
qui semble être efficace. Esce un choix encore meilleur ?
La version normale est déjà très rapide. Je n'ai pas fait de test en mode "no-sync".
Sebastien
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Seb wrote:
"Remi Thomas" <remi@xtware.com> a écrit dans le message news:
3ffe81b7$0$17135$626a54ce@news.free.fr
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base
de données vers une base proposant une API qui soit facilement
"codable"
en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé
développer une DLL avec le "free command line" de Borland (là ça
fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas
d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ?
http://www.hwaci.com/sw/sqlite/
Rémi
Ce choix a l'air judicieux, l'as-tu déjà implémenté ?
Oui, et fonctionne très bien.
C'est le nouveau moteur de base de données par défaut dans PHP5 vu le
changement de licence pour MySQL.
En survolant leur site j'ai vu 2 version : normale et "no-sync". C'est la
seconde
qui semble être efficace. Esce un choix encore meilleur ?
La version normale est déjà très rapide. Je n'ai pas fait de test en mode
"no-sync".
Sebastien
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
"Remi Thomas" a écrit dans le message news: 3ffe81b7$0$17135$
Seb wrote:
Bonjour,
Suite à quelques déboires avec Paradox, je souhaite migrer ma base de données vers une base proposant une API qui soit facilement "codable" en C++ (Borland C++ et non builder).
MySql propose une telle API mais c'est pour Builder. J'ai bien pensé développer une DLL avec le "free command line" de Borland (là ça fonctionne) et ensuite utiliser cette DLL, mais je n'ai pas d'expérience dans ce genre d'architecture. Qu'en pensez-vous ?
Sébastien
SQLite ? http://www.hwaci.com/sw/sqlite/
Rémi
Ce choix a l'air judicieux, l'as-tu déjà implémenté ?
Oui, et fonctionne très bien. C'est le nouveau moteur de base de données par défaut dans PHP5 vu le changement de licence pour MySQL.
En survolant leur site j'ai vu 2 version : normale et "no-sync". C'est la
seconde
qui semble être efficace. Esce un choix encore meilleur ?
La version normale est déjà très rapide. Je n'ai pas fait de test en mode "no-sync".
Sebastien
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Ambassadeur Kosh
> > physiquement, c'est du COM. faut pas être allergique c'est tout... En client c'est pas la mort, COM. J'ai trouvé ADO bien plus facile a utiliser qu'ODBC.
<troll> certes, mais certains sont sujets à ce genre d'allergie. ils sont allergiques aux classes et preferent écrire des fonctions, ils eternuent à chaque parametre et preferent mettre des vars globales, ils ont des boutons quand on a une fonction inline et remplacent vite tout ça par un trés bon define, les assert provoquent des vomissements et les templates des troubles depressifs, alors le COM, faut voir :o) </troll>
> > physiquement, c'est du COM. faut pas être allergique c'est tout...
En client c'est pas la mort, COM.
J'ai trouvé ADO bien plus facile a utiliser qu'ODBC.
<troll>
certes, mais certains sont sujets à ce genre d'allergie. ils sont
allergiques aux classes et preferent écrire des fonctions, ils eternuent à
chaque parametre et preferent mettre des vars globales, ils ont des boutons
quand on a une fonction inline et remplacent vite tout ça par un trés bon
define, les assert provoquent des vomissements et les templates des troubles
depressifs, alors le COM, faut voir :o)
</troll>
> > physiquement, c'est du COM. faut pas être allergique c'est tout... En client c'est pas la mort, COM. J'ai trouvé ADO bien plus facile a utiliser qu'ODBC.
<troll> certes, mais certains sont sujets à ce genre d'allergie. ils sont allergiques aux classes et preferent écrire des fonctions, ils eternuent à chaque parametre et preferent mettre des vars globales, ils ont des boutons quand on a une fonction inline et remplacent vite tout ça par un trés bon define, les assert provoquent des vomissements et les templates des troubles depressifs, alors le COM, faut voir :o) </troll>
