je vais poser une question sans doute idiote : est il possible d'utiliser le
DataReport sous DAO......(je suppose que non, qu'il est réservé a ADO...non
?)
dav
je vais poser une question sans doute idiote : est il possible d'utiliser le
DataReport sous DAO......(je suppose que non, qu'il est réservé a ADO...non
?)
dav
je vais poser une question sans doute idiote : est il possible d'utiliser le
DataReport sous DAO......(je suppose que non, qu'il est réservé a ADO...non
?)
dav
Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette croyance
populaire est surtout due au fait que DAO est made in Microsoft et qu'Access
l'est aussi et que ce dernier est orienté fichier et non client-serveur.
Donc facile à mettre en place pour l'apprentissage et la diffusion
d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des base
de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION, SQL
ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice d'être
plus simple mais moins perfectionné et ne répondant pas aux dernières
technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est pas
meilleur que DAO, voire le contraire. Mais ADO devenant un standard de
fait, nous n'avons pas trop le choix hormis peut-être d'utliser le modèle
objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce que je fait
avec ORACLE. J'utilise son modèle objet et non celui de Microsoft.
Performance garantie !
Guy
"jmn" a écrit dans le message de news:
%Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette croyance
populaire est surtout due au fait que DAO est made in Microsoft et qu'Access
l'est aussi et que ce dernier est orienté fichier et non client-serveur.
Donc facile à mettre en place pour l'apprentissage et la diffusion
d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des base
de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION, SQL
ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice d'être
plus simple mais moins perfectionné et ne répondant pas aux dernières
technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est pas
meilleur que DAO, voire le contraire. Mais ADO devenant un standard de
fait, nous n'avons pas trop le choix hormis peut-être d'utliser le modèle
objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce que je fait
avec ORACLE. J'utilise son modèle objet et non celui de Microsoft.
Performance garantie !
Guy
"jmn" <jmn@truc.com> a écrit dans le message de news:
%23CP41AE2EHA.3840@tk2msftngp13.phx.gbl...
Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette croyance
populaire est surtout due au fait que DAO est made in Microsoft et qu'Access
l'est aussi et que ce dernier est orienté fichier et non client-serveur.
Donc facile à mettre en place pour l'apprentissage et la diffusion
d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des base
de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION, SQL
ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice d'être
plus simple mais moins perfectionné et ne répondant pas aux dernières
technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est pas
meilleur que DAO, voire le contraire. Mais ADO devenant un standard de
fait, nous n'avons pas trop le choix hormis peut-être d'utliser le modèle
objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce que je fait
avec ORACLE. J'utilise son modèle objet et non celui de Microsoft.
Performance garantie !
Guy
"jmn" a écrit dans le message de news:
%Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
donc si j'ai bien compris, DAO + DataReport : niet !
il me reste crystal report...hélas peu de doc sur la question....
il n'en reste pas moins que je trouve dommage qu'a part utiliser des Print
à tout bout de champ ( et c'est quand même pas tres souple...) il n'existe
pas d'autres moyens de créer une état propre avec le résultat d'une
requête SQL sous DAO et access.....
merci de vos réponses,
dav
Guy DETIENNE a écrit :Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette
croyance populaire est surtout due au fait que DAO est made in Microsoft
et qu'Access l'est aussi et que ce dernier est orienté fichier et non
client-serveur. Donc facile à mettre en place pour l'apprentissage et la
diffusion d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des
base de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION,
SQL ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice
d'être plus simple mais moins perfectionné et ne répondant pas aux
dernières technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est
pas meilleur que DAO, voire le contraire. Mais ADO devenant un standard
de fait, nous n'avons pas trop le choix hormis peut-être d'utliser le
modèle objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce
que je fait avec ORACLE. J'utilise son modèle objet et non celui de
Microsoft. Performance garantie !
Guy
"jmn" a écrit dans le message de news:
%Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
donc si j'ai bien compris, DAO + DataReport : niet !
il me reste crystal report...hélas peu de doc sur la question....
il n'en reste pas moins que je trouve dommage qu'a part utiliser des Print
à tout bout de champ ( et c'est quand même pas tres souple...) il n'existe
pas d'autres moyens de créer une état propre avec le résultat d'une
requête SQL sous DAO et access.....
merci de vos réponses,
dav
Guy DETIENNE a écrit :
Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette
croyance populaire est surtout due au fait que DAO est made in Microsoft
et qu'Access l'est aussi et que ce dernier est orienté fichier et non
client-serveur. Donc facile à mettre en place pour l'apprentissage et la
diffusion d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des
base de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION,
SQL ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice
d'être plus simple mais moins perfectionné et ne répondant pas aux
dernières technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est
pas meilleur que DAO, voire le contraire. Mais ADO devenant un standard
de fait, nous n'avons pas trop le choix hormis peut-être d'utliser le
modèle objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce
que je fait avec ORACLE. J'utilise son modèle objet et non celui de
Microsoft. Performance garantie !
Guy
"jmn" <jmn@truc.com> a écrit dans le message de news:
%23CP41AE2EHA.3840@tk2msftngp13.phx.gbl...
Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
donc si j'ai bien compris, DAO + DataReport : niet !
il me reste crystal report...hélas peu de doc sur la question....
il n'en reste pas moins que je trouve dommage qu'a part utiliser des Print
à tout bout de champ ( et c'est quand même pas tres souple...) il n'existe
pas d'autres moyens de créer une état propre avec le résultat d'une
requête SQL sous DAO et access.....
merci de vos réponses,
dav
Guy DETIENNE a écrit :Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette
croyance populaire est surtout due au fait que DAO est made in Microsoft
et qu'Access l'est aussi et que ce dernier est orienté fichier et non
client-serveur. Donc facile à mettre en place pour l'apprentissage et la
diffusion d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des
base de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION,
SQL ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice
d'être plus simple mais moins perfectionné et ne répondant pas aux
dernières technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est
pas meilleur que DAO, voire le contraire. Mais ADO devenant un standard
de fait, nous n'avons pas trop le choix hormis peut-être d'utliser le
modèle objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce
que je fait avec ORACLE. J'utilise son modèle objet et non celui de
Microsoft. Performance garantie !
Guy
"jmn" a écrit dans le message de news:
%Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Quand je parle d'abération je ne parle pas de ta question... Mais le fait
que DAO ne serait orienté qu'avec Access...
Le datareport est tout à fait compatible avec DAO !
Guy
"dav" a écrit dans le message de news:
41b02fc0$0$11754$donc si j'ai bien compris, DAO + DataReport : niet !
il me reste crystal report...hélas peu de doc sur la question....
il n'en reste pas moins que je trouve dommage qu'a part utiliser des Print
à tout bout de champ ( et c'est quand même pas tres souple...) il n'existe
pas d'autres moyens de créer une état propre avec le résultat d'une requête
SQL sous DAO et access.....
merci de vos réponses,
dav
Guy DETIENNE a écrit :Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette
croyance populaire est surtout due au fait que DAO est made in Microsoft
et qu'Access l'est aussi et que ce dernier est orienté fichier et non
client-serveur. Donc facile à mettre en place pour l'apprentissage et la
diffusion d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des
base de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION,
SQL ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice
d'être plus simple mais moins perfectionné et ne répondant pas aux
dernières technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est
pas meilleur que DAO, voire le contraire. Mais ADO devenant un standard
de fait, nous n'avons pas trop le choix hormis peut-être d'utliser le
modèle objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce que
je fait avec ORACLE. J'utilise son modèle objet et non celui de
Microsoft. Performance garantie !
Guy
"jmn" a écrit dans le message de news:
%Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Quand je parle d'abération je ne parle pas de ta question... Mais le fait
que DAO ne serait orienté qu'avec Access...
Le datareport est tout à fait compatible avec DAO !
Guy
"dav" <dav49400-spam@wanadoo.fr> a écrit dans le message de news:
41b02fc0$0$11754$8fcfb975@news.wanadoo.fr...
donc si j'ai bien compris, DAO + DataReport : niet !
il me reste crystal report...hélas peu de doc sur la question....
il n'en reste pas moins que je trouve dommage qu'a part utiliser des Print
à tout bout de champ ( et c'est quand même pas tres souple...) il n'existe
pas d'autres moyens de créer une état propre avec le résultat d'une requête
SQL sous DAO et access.....
merci de vos réponses,
dav
Guy DETIENNE a écrit :
Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette
croyance populaire est surtout due au fait que DAO est made in Microsoft
et qu'Access l'est aussi et que ce dernier est orienté fichier et non
client-serveur. Donc facile à mettre en place pour l'apprentissage et la
diffusion d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des
base de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION,
SQL ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice
d'être plus simple mais moins perfectionné et ne répondant pas aux
dernières technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est
pas meilleur que DAO, voire le contraire. Mais ADO devenant un standard
de fait, nous n'avons pas trop le choix hormis peut-être d'utliser le
modèle objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce que
je fait avec ORACLE. J'utilise son modèle objet et non celui de
Microsoft. Performance garantie !
Guy
"jmn" <jmn@truc.com> a écrit dans le message de news:
%23CP41AE2EHA.3840@tk2msftngp13.phx.gbl...
Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Quand je parle d'abération je ne parle pas de ta question... Mais le fait
que DAO ne serait orienté qu'avec Access...
Le datareport est tout à fait compatible avec DAO !
Guy
"dav" a écrit dans le message de news:
41b02fc0$0$11754$donc si j'ai bien compris, DAO + DataReport : niet !
il me reste crystal report...hélas peu de doc sur la question....
il n'en reste pas moins que je trouve dommage qu'a part utiliser des Print
à tout bout de champ ( et c'est quand même pas tres souple...) il n'existe
pas d'autres moyens de créer une état propre avec le résultat d'une requête
SQL sous DAO et access.....
merci de vos réponses,
dav
Guy DETIENNE a écrit :Salut,
Où as-tu appris cette abération !
DAO n'est pas du tout orienté vers le travail avec Access ! Cette
croyance populaire est surtout due au fait que DAO est made in Microsoft
et qu'Access l'est aussi et que ce dernier est orienté fichier et non
client-serveur. Donc facile à mettre en place pour l'apprentissage et la
diffusion d'exemples tout fait.
DAO au même titre qu'ADO est un objet permettant de travailler avec des
base de données.
Il te suffit de passer par ODBC avec DAO et tu utilises n'importe quelle
SGDB pasant de ORACLE à INFORMIX ou encore SQL Server, DB2, 4eDIMENSION,
SQL ANYMWHERE, j'en passe et des meilleurs tant qu'un driver ODBC existe.
Mais il est vrai que DAO tombe en désuétude au profit de ADO. Donc pour
tout nouveau projet, il est conseillé d'utiliser ce dernier.
ADO est plus lourd à mettre en place tandis que DAO avait le bénéfice
d'être plus simple mais moins perfectionné et ne répondant pas aux
dernières technologies.
Tu devrais chercher sur le net des comparaitfs 'objectifs' concernant les
deux technologies. Tu seras étonné de voir que selon les cas, ADO n'est
pas meilleur que DAO, voire le contraire. Mais ADO devenant un standard
de fait, nous n'avons pas trop le choix hormis peut-être d'utliser le
modèle objet livré par les éditeurs eux-mêmes (s'il existe). C'est ce que
je fait avec ORACLE. J'utilise son modèle objet et non celui de
Microsoft. Performance garantie !
Guy
"jmn" a écrit dans le message de news:
%Vous aurez remarqué que si DAO est trés nettement orienté vers le travail
avec Access, ADO se veut une interface généraliste qui permet de
travailler
avec tous les SGBD du marché. Donc, même si cet outil dont vous parlez ne
travaille qu'en ADO et que vous gérez vos données en DAO, rien ne vous
empèche de vous en servir...
Cher Guy DETIENNE,
'cette abération !' vient du fait que DAO, ou plutôt le moteur JET, a pour
format natif de base de données le format MDB, que l'on nomme
habituellement
Access !
Historiquement, essentiellement pour assurer le portage des applications
Dbase du début des années 90, les développeurs Microsoft ont prévu des
formats externes intégrés dit 'ISAM' (paradox, dbase xxx, btrieve) et une
passerelle intégrée vers ODBC.
Et vous conviendrez que, d'un système dans lequel toutes les définitions
implicites renvoient vers le format Access (JET x.x pour les puristes), on
peut dire qu'il est "trés nettement orienté vers le travail avec
Access..."
(i.e : .. vers le travail avec des bases de données au format natif JET).
Cher Guy DETIENNE,
'cette abération !' vient du fait que DAO, ou plutôt le moteur JET, a pour
format natif de base de données le format MDB, que l'on nomme
habituellement
Access !
Historiquement, essentiellement pour assurer le portage des applications
Dbase du début des années 90, les développeurs Microsoft ont prévu des
formats externes intégrés dit 'ISAM' (paradox, dbase xxx, btrieve) et une
passerelle intégrée vers ODBC.
Et vous conviendrez que, d'un système dans lequel toutes les définitions
implicites renvoient vers le format Access (JET x.x pour les puristes), on
peut dire qu'il est "trés nettement orienté vers le travail avec
Access..."
(i.e : .. vers le travail avec des bases de données au format natif JET).
Cher Guy DETIENNE,
'cette abération !' vient du fait que DAO, ou plutôt le moteur JET, a pour
format natif de base de données le format MDB, que l'on nomme
habituellement
Access !
Historiquement, essentiellement pour assurer le portage des applications
Dbase du début des années 90, les développeurs Microsoft ont prévu des
formats externes intégrés dit 'ISAM' (paradox, dbase xxx, btrieve) et une
passerelle intégrée vers ODBC.
Et vous conviendrez que, d'un système dans lequel toutes les définitions
implicites renvoient vers le format Access (JET x.x pour les puristes), on
peut dire qu'il est "trés nettement orienté vers le travail avec
Access..."
(i.e : .. vers le travail avec des bases de données au format natif JET).
