Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Philippot
Jean Elens wrote:
Quelqu'un pourrais me dire comment en VB6, faire un select sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle, table_mssql where data_mssqlÚta_oracle ?
Bonjour,
Je ne crois pas que le broadcast de requêtes multi-SGBD soit disponible :-))) C'est peut-être beaucoup demander, non? Ce n'est déjà pas facile de gérer un transaction sur une seule source mais là, ça relèverait du casse-tête (à moins que je n'aie loupé une avancée technologique majeure).
Le mieux est de lancer 2 requêtes asynchrones distinctes depuis votre appli et de réconcilier / fusionner les données en local une fois les 2 requêtes terminées.
Si au lieu de faire du client serveur, vous faites du multiniveaux, mettez en place un objet métier sur le deuxième niveau qui se chargera de l'opération dans le cadre d'une transaction logique unique (COM+ par exemple) et qui restituera le résultat au client.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Jean Elens wrote:
Quelqu'un pourrais me dire comment en VB6, faire un select
sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle,
table_mssql where data_mssqlÚta_oracle ?
Bonjour,
Je ne crois pas que le broadcast de requêtes multi-SGBD soit disponible
:-))) C'est peut-être beaucoup demander, non? Ce n'est déjà pas facile
de gérer un transaction sur une seule source mais là, ça relèverait du
casse-tête (à moins que je n'aie loupé une avancée technologique
majeure).
Le mieux est de lancer 2 requêtes asynchrones distinctes depuis votre
appli et de réconcilier / fusionner les données en local une fois les 2
requêtes terminées.
Si au lieu de faire du client serveur, vous faites du multiniveaux,
mettez en place un objet métier sur le deuxième niveau qui se chargera
de l'opération dans le cadre d'une transaction logique unique (COM+ par
exemple) et qui restituera le résultat au client.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Quelqu'un pourrais me dire comment en VB6, faire un select sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle, table_mssql where data_mssqlÚta_oracle ?
Bonjour,
Je ne crois pas que le broadcast de requêtes multi-SGBD soit disponible :-))) C'est peut-être beaucoup demander, non? Ce n'est déjà pas facile de gérer un transaction sur une seule source mais là, ça relèverait du casse-tête (à moins que je n'aie loupé une avancée technologique majeure).
Le mieux est de lancer 2 requêtes asynchrones distinctes depuis votre appli et de réconcilier / fusionner les données en local une fois les 2 requêtes terminées.
Si au lieu de faire du client serveur, vous faites du multiniveaux, mettez en place un objet métier sur le deuxième niveau qui se chargera de l'opération dans le cadre d'une transaction logique unique (COM+ par exemple) et qui restituera le résultat au client.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Quasimodo
Patrick Philippot formulated on Wednesday :
Jean Elens wrote:
Quelqu'un pourrais me dire comment en VB6, faire un select sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle, table_mssql where data_mssqlÚta_oracle ?
Bonjour,
Je ne crois pas que le broadcast de requêtes multi-SGBD soit disponible :-))) C'est peut-être beaucoup demander, non? Ce n'est déjà pas facile de gérer un transaction sur une seule source mais là, ça relèverait du casse-tête (à moins que je n'aie loupé une avancée technologique majeure).
Le mieux est de lancer 2 requêtes asynchrones distinctes depuis votre appli et de réconcilier / fusionner les données en local une fois les 2 requêtes terminées.
Si au lieu de faire du client serveur, vous faites du multiniveaux, mettez en place un objet métier sur le deuxième niveau qui se chargera de l'opération dans le cadre d'une transaction logique unique (COM+ par exemple) et qui restituera le résultat au client.
Bonjour, pour les transactions multi db, il existe bien un gestionnaire (je pense à ms dts). Pour utiliser des data provenant de plusieurs db, soit vous passez par du multiniveau comme dit Patrick. Soit vous laisser ce travaille à votre db (donc une seul source odbc). Vous pouvez très bien passer par sql server pour faire votre vue sur oracle et une autre vue mySQL ...
@+ Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
Patrick Philippot formulated on Wednesday :
Jean Elens wrote:
Quelqu'un pourrais me dire comment en VB6, faire un select
sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle,
table_mssql where data_mssqlÚta_oracle ?
Bonjour,
Je ne crois pas que le broadcast de requêtes multi-SGBD soit disponible
:-))) C'est peut-être beaucoup demander, non? Ce n'est déjà pas facile
de gérer un transaction sur une seule source mais là, ça relèverait du
casse-tête (à moins que je n'aie loupé une avancée technologique
majeure).
Le mieux est de lancer 2 requêtes asynchrones distinctes depuis votre
appli et de réconcilier / fusionner les données en local une fois les 2
requêtes terminées.
Si au lieu de faire du client serveur, vous faites du multiniveaux,
mettez en place un objet métier sur le deuxième niveau qui se chargera
de l'opération dans le cadre d'une transaction logique unique (COM+ par
exemple) et qui restituera le résultat au client.
Bonjour,
pour les transactions multi db, il existe bien un gestionnaire (je
pense à ms dts).
Pour utiliser des data provenant de plusieurs db, soit vous passez par
du multiniveau comme dit Patrick. Soit vous laisser ce travaille à
votre db (donc une seul source odbc). Vous pouvez très bien passer par
sql server pour faire votre vue sur oracle et une autre vue mySQL ...
@+ Quaz
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Quelqu'un pourrais me dire comment en VB6, faire un select sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle, table_mssql where data_mssqlÚta_oracle ?
Bonjour,
Je ne crois pas que le broadcast de requêtes multi-SGBD soit disponible :-))) C'est peut-être beaucoup demander, non? Ce n'est déjà pas facile de gérer un transaction sur une seule source mais là, ça relèverait du casse-tête (à moins que je n'aie loupé une avancée technologique majeure).
Le mieux est de lancer 2 requêtes asynchrones distinctes depuis votre appli et de réconcilier / fusionner les données en local une fois les 2 requêtes terminées.
Si au lieu de faire du client serveur, vous faites du multiniveaux, mettez en place un objet métier sur le deuxième niveau qui se chargera de l'opération dans le cadre d'une transaction logique unique (COM+ par exemple) et qui restituera le résultat au client.
Bonjour, pour les transactions multi db, il existe bien un gestionnaire (je pense à ms dts). Pour utiliser des data provenant de plusieurs db, soit vous passez par du multiniveau comme dit Patrick. Soit vous laisser ce travaille à votre db (donc une seul source odbc). Vous pouvez très bien passer par sql server pour faire votre vue sur oracle et une autre vue mySQL ...
@+ Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
Alfred Wallace
Bonjour,
La liaison de tables dans Access me parait tout à fait adaptée à ce genre de manipulations. Dans certaines applis, j'utilise une base access ne contenant que des liaisons vers des tables de bases DBASE5 et MySql.
Juste que je crée ces liens par Access car je ne sais pas le faire directement par programme VB.
Pour le reste, par programme on ouvre la base lien comme une base ordinaire, puis lors du select il suffit de préciser les tables concernées: Select TbDb5.* , TbMySql.* FROM BaseAccessLien WHERE ...........
Les temps sont un peu plus longs selon ce que l'on cherche à lire.
Cela fonctionne. Luc
"Jean Elens" a écrit dans le message de news:158201c4a099$8c6a1760$
Quelqu'un pourrais me dire comment en VB6, faire un select sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle, table_mssql where data_mssqlÚta_oracle ?
Thx
Bonjour,
La liaison de tables dans Access me parait tout à fait adaptée à ce genre de
manipulations.
Dans certaines applis, j'utilise une base access ne contenant que des
liaisons vers des tables de bases DBASE5 et MySql.
Juste que je crée ces liens par Access car je ne sais pas le faire
directement par programme VB.
Pour le reste, par programme on ouvre la base lien comme une base ordinaire,
puis lors du select il suffit de préciser les tables concernées:
Select TbDb5.* , TbMySql.* FROM BaseAccessLien
WHERE ...........
Les temps sont un peu plus longs selon ce que l'on cherche à lire.
Cela fonctionne.
Luc
"Jean Elens" <jean.elens@banksys.be> a écrit dans le message de
news:158201c4a099$8c6a1760$a601280a@phx.gbl...
Quelqu'un pourrais me dire comment en VB6, faire un select
sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle,
table_mssql where data_mssqlÚta_oracle ?
La liaison de tables dans Access me parait tout à fait adaptée à ce genre de manipulations. Dans certaines applis, j'utilise une base access ne contenant que des liaisons vers des tables de bases DBASE5 et MySql.
Juste que je crée ces liens par Access car je ne sais pas le faire directement par programme VB.
Pour le reste, par programme on ouvre la base lien comme une base ordinaire, puis lors du select il suffit de préciser les tables concernées: Select TbDb5.* , TbMySql.* FROM BaseAccessLien WHERE ...........
Les temps sont un peu plus longs selon ce que l'on cherche à lire.
Cela fonctionne. Luc
"Jean Elens" a écrit dans le message de news:158201c4a099$8c6a1760$
Quelqu'un pourrais me dire comment en VB6, faire un select sur plusieurs tables d'odbc differents.
select data_oracle, data_ms_sql from table_oracle, table_mssql where data_mssqlÚta_oracle ?
Thx
Patrick Philippot
Bonjour,
Alfred Wallace wrote:
La liaison de tables dans Access me parait tout à fait adaptée à ce genre de manipulations. Dans certaines applis, j'utilise une base access ne contenant que des liaisons vers des tables de bases DBASE5 et MySql.
Oui, nous avons vu que cela était possible dans d'autres environnements également ou en passant par un objet métier intermédiaire. Mais je comprends la question autrement (sauf erreur de ma part): la demande est de pouvoir faire via ODBC une requête unique sur plusieurs sources de données différentes. Par ailleurs, si Jean nous disait quelle technologie il utilise, cela aiderait un peu: DAO Jet, ADO?
Avec DAO Jet on peut créer dynamiquement (par programme) des tables liées (linked tables). On peut également avec ADOX si je ne me trompe. Mais la notion de "linked table" est propre à Access / DAO. Quid si les données de Jean ne se trouvent pas dans une source de données de ce type?
Bref, je pense que dans tous les cas, il faut un "middle-man" qui sert d'intégrateur entre les différentes data sources et le code client et présentent à ce dernier une source de données virtuellement unique. Dans le cas de DAO, Access peut jouer ce rôle, comme vous l'avez décrit. Sinon, il faut un produit qui sert d'interface. Il y en a de nombreux sur le marché: par exemple Intersolv (MicroFocus) DataDirect,... qui supporte le concept de "Common Server DBMS Interface". Ce type de produit propose une interface ODBC unifiée et transparente pour des sources ODBC multiples. Il y en a d'autres. L'existence même de ces produits sur le marché démontre que l'opération ne peut pas se réaliser simplement avec les outils de base.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Alfred Wallace wrote:
La liaison de tables dans Access me parait tout à fait adaptée à ce
genre de manipulations.
Dans certaines applis, j'utilise une base access ne contenant que des
liaisons vers des tables de bases DBASE5 et MySql.
Oui, nous avons vu que cela était possible dans d'autres environnements
également ou en passant par un objet métier intermédiaire. Mais je
comprends la question autrement (sauf erreur de ma part): la demande est
de pouvoir faire via ODBC une requête unique sur plusieurs sources de
données différentes. Par ailleurs, si Jean nous disait quelle
technologie il utilise, cela aiderait un peu: DAO Jet, ADO?
Avec DAO Jet on peut créer dynamiquement (par programme) des tables
liées (linked tables). On peut également avec ADOX si je ne me trompe.
Mais la notion de "linked table" est propre à Access / DAO. Quid si les
données de Jean ne se trouvent pas dans une source de données de ce
type?
Bref, je pense que dans tous les cas, il faut un "middle-man" qui sert
d'intégrateur entre les différentes data sources et le code client et
présentent à ce dernier une source de données virtuellement unique. Dans
le cas de DAO, Access peut jouer ce rôle, comme vous l'avez décrit.
Sinon, il faut un produit qui sert d'interface. Il y en a de nombreux
sur le marché: par exemple Intersolv (MicroFocus) DataDirect,... qui
supporte le concept de "Common Server DBMS Interface". Ce type de
produit propose une interface ODBC unifiée et transparente pour des
sources ODBC multiples. Il y en a d'autres. L'existence même de ces
produits sur le marché démontre que l'opération ne peut pas se réaliser
simplement avec les outils de base.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
La liaison de tables dans Access me parait tout à fait adaptée à ce genre de manipulations. Dans certaines applis, j'utilise une base access ne contenant que des liaisons vers des tables de bases DBASE5 et MySql.
Oui, nous avons vu que cela était possible dans d'autres environnements également ou en passant par un objet métier intermédiaire. Mais je comprends la question autrement (sauf erreur de ma part): la demande est de pouvoir faire via ODBC une requête unique sur plusieurs sources de données différentes. Par ailleurs, si Jean nous disait quelle technologie il utilise, cela aiderait un peu: DAO Jet, ADO?
Avec DAO Jet on peut créer dynamiquement (par programme) des tables liées (linked tables). On peut également avec ADOX si je ne me trompe. Mais la notion de "linked table" est propre à Access / DAO. Quid si les données de Jean ne se trouvent pas dans une source de données de ce type?
Bref, je pense que dans tous les cas, il faut un "middle-man" qui sert d'intégrateur entre les différentes data sources et le code client et présentent à ce dernier une source de données virtuellement unique. Dans le cas de DAO, Access peut jouer ce rôle, comme vous l'avez décrit. Sinon, il faut un produit qui sert d'interface. Il y en a de nombreux sur le marché: par exemple Intersolv (MicroFocus) DataDirect,... qui supporte le concept de "Common Server DBMS Interface". Ce type de produit propose une interface ODBC unifiée et transparente pour des sources ODBC multiples. Il y en a d'autres. L'existence même de ces produits sur le marché démontre que l'opération ne peut pas se réaliser simplement avec les outils de base.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Alfred Wallace
Un grand merci pour ce complément d'infos Luc
"Patrick Philippot" a écrit dans le message de news:OlB8$
Bonjour,
Alfred Wallace wrote: > La liaison de tables dans Access me parait tout à fait adaptée à ce > genre de manipulations. > Dans certaines applis, j'utilise une base access ne contenant que des > liaisons vers des tables de bases DBASE5 et MySql.
Oui, nous avons vu que cela était possible dans d'autres environnements également ou en passant par un objet métier intermédiaire. Mais je comprends la question autrement (sauf erreur de ma part): la demande est de pouvoir faire via ODBC une requête unique sur plusieurs sources de données différentes. Par ailleurs, si Jean nous disait quelle technologie il utilise, cela aiderait un peu: DAO Jet, ADO?
Avec DAO Jet on peut créer dynamiquement (par programme) des tables liées (linked tables). On peut également avec ADOX si je ne me trompe. Mais la notion de "linked table" est propre à Access / DAO. Quid si les données de Jean ne se trouvent pas dans une source de données de ce type?
Bref, je pense que dans tous les cas, il faut un "middle-man" qui sert d'intégrateur entre les différentes data sources et le code client et présentent à ce dernier une source de données virtuellement unique. Dans le cas de DAO, Access peut jouer ce rôle, comme vous l'avez décrit. Sinon, il faut un produit qui sert d'interface. Il y en a de nombreux sur le marché: par exemple Intersolv (MicroFocus) DataDirect,... qui supporte le concept de "Common Server DBMS Interface". Ce type de produit propose une interface ODBC unifiée et transparente pour des sources ODBC multiples. Il y en a d'autres. L'existence même de ces produits sur le marché démontre que l'opération ne peut pas se réaliser simplement avec les outils de base.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Un grand merci pour ce complément d'infos
Luc
"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
de news:OlB8$9goEHA.3324@TK2MSFTNGP15.phx.gbl...
Bonjour,
Alfred Wallace wrote:
> La liaison de tables dans Access me parait tout à fait adaptée à ce
> genre de manipulations.
> Dans certaines applis, j'utilise une base access ne contenant que des
> liaisons vers des tables de bases DBASE5 et MySql.
Oui, nous avons vu que cela était possible dans d'autres environnements
également ou en passant par un objet métier intermédiaire. Mais je
comprends la question autrement (sauf erreur de ma part): la demande est
de pouvoir faire via ODBC une requête unique sur plusieurs sources de
données différentes. Par ailleurs, si Jean nous disait quelle
technologie il utilise, cela aiderait un peu: DAO Jet, ADO?
Avec DAO Jet on peut créer dynamiquement (par programme) des tables
liées (linked tables). On peut également avec ADOX si je ne me trompe.
Mais la notion de "linked table" est propre à Access / DAO. Quid si les
données de Jean ne se trouvent pas dans une source de données de ce
type?
Bref, je pense que dans tous les cas, il faut un "middle-man" qui sert
d'intégrateur entre les différentes data sources et le code client et
présentent à ce dernier une source de données virtuellement unique. Dans
le cas de DAO, Access peut jouer ce rôle, comme vous l'avez décrit.
Sinon, il faut un produit qui sert d'interface. Il y en a de nombreux
sur le marché: par exemple Intersolv (MicroFocus) DataDirect,... qui
supporte le concept de "Common Server DBMS Interface". Ce type de
produit propose une interface ODBC unifiée et transparente pour des
sources ODBC multiples. Il y en a d'autres. L'existence même de ces
produits sur le marché démontre que l'opération ne peut pas se réaliser
simplement avec les outils de base.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
"Patrick Philippot" a écrit dans le message de news:OlB8$
Bonjour,
Alfred Wallace wrote: > La liaison de tables dans Access me parait tout à fait adaptée à ce > genre de manipulations. > Dans certaines applis, j'utilise une base access ne contenant que des > liaisons vers des tables de bases DBASE5 et MySql.
Oui, nous avons vu que cela était possible dans d'autres environnements également ou en passant par un objet métier intermédiaire. Mais je comprends la question autrement (sauf erreur de ma part): la demande est de pouvoir faire via ODBC une requête unique sur plusieurs sources de données différentes. Par ailleurs, si Jean nous disait quelle technologie il utilise, cela aiderait un peu: DAO Jet, ADO?
Avec DAO Jet on peut créer dynamiquement (par programme) des tables liées (linked tables). On peut également avec ADOX si je ne me trompe. Mais la notion de "linked table" est propre à Access / DAO. Quid si les données de Jean ne se trouvent pas dans une source de données de ce type?
Bref, je pense que dans tous les cas, il faut un "middle-man" qui sert d'intégrateur entre les différentes data sources et le code client et présentent à ce dernier une source de données virtuellement unique. Dans le cas de DAO, Access peut jouer ce rôle, comme vous l'avez décrit. Sinon, il faut un produit qui sert d'interface. Il y en a de nombreux sur le marché: par exemple Intersolv (MicroFocus) DataDirect,... qui supporte le concept de "Common Server DBMS Interface". Ce type de produit propose une interface ODBC unifiée et transparente pour des sources ODBC multiples. Il y en a d'autres. L'existence même de ces produits sur le marché démontre que l'opération ne peut pas se réaliser simplement avec les outils de base.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
