mon problème : établir une liaison vers une base de donnée Acces sur
W2000 depuis Filemaker 604 sur Mac OSX 10.3.2
1) la base Acces est accessible, j'y accède avec Acces sur un autre
poste W98 et depuis FMP sur le W2k et W98 ; Depuis le Mac, j'accède au
repertoire partagé du W2k sur lequel se trouve la base xxx.mdb
correspondant à la base Access, je peux y écrire, lire et détruire des
fichiers. Faut-il des droits supplémentaires ?
2) j'ai installé le package Configuration Manager de DATA Direct sur le
Mac (fourni avec FMP). Sur le mac, on repère le pilote ODBC de FMP :
Filemaker ODBC 4.0 Text Driver.
les diverses aides sur la configuration de ce truc ne sont pas vraiment
explicites...
J'essaie de définir un DSN Utilisateur sur le Mac. Je le nomme comme je
veux, mais ensuite, quand il s'agit de définir un chemin, j'arrive à la
base .mdb mais elle reste en grisé. Faut-il dire quelque part le genre
de table (Default Table Type ne me propose que comma, character, fixed,
stream et tab : que choisir ?). Je choisis donc un repertoire, mais
ensuite dans FMP, quand j'indique ouvrir une base ODBC , que je choisis
le partage en question avec le mot de passe indiqué dans la base, il me
dit [dataDirect][ODBC TEXT driver]initialisation file is not open (1).
j'ai en fait l'impression que le pilote ODBC FMP ne sait pas accéder à
une base MDB ; il n'y a rien à faire ?
Si je comprends bien la philosophie du partage de données ODBC, c'est
directement le fichier qui est partagé, il n'est pas distribué par une
application résident sur le serveur ?
merci de me mettre une copie de votre éventuelle réponse en bal, je n'ai
pas accès aux news au boulot (et vous vous doutez bien que je n'ai pas
de base acces chez moi !!!)
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
Hubert Figuiere
j'ai en fait l'impression que le pilote ODBC FMP ne sait pas accéder à une base MDB ; il n'y a rien à faire ?
Ben disons que sur Windows il a besoin d'Access pour ca. Y'a pas Access sur Mac.
Si je comprends bien la philosophie du partage de données ODBC, c'est directement le fichier qui est partagé, il n'est pas distribué par une application résident sur le serveur ?
Non. C'est Access hein !
Solution: migrer la base sur un vrai SGBD. MySQL devrait suffire.
j'ai en fait l'impression que le pilote ODBC FMP ne sait pas accéder à
une base MDB ; il n'y a rien à faire ?
Ben disons que sur Windows il a besoin d'Access pour ca. Y'a pas
Access sur Mac.
Si je comprends bien la philosophie du partage de données ODBC, c'est
directement le fichier qui est partagé, il n'est pas distribué par une
application résident sur le serveur ?
Non. C'est Access hein !
Solution: migrer la base sur un vrai SGBD. MySQL devrait suffire.
j'ai en fait l'impression que le pilote ODBC FMP ne sait pas accéder à une base MDB ; il n'y a rien à faire ?
Ben disons que sur Windows il a besoin d'Access pour ca. Y'a pas Access sur Mac.
Si je comprends bien la philosophie du partage de données ODBC, c'est directement le fichier qui est partagé, il n'est pas distribué par une application résident sur le serveur ?
Non. C'est Access hein !
Solution: migrer la base sur un vrai SGBD. MySQL devrait suffire.
Solution: migrer la base sur un vrai SGBD. MySQL devrait suffire.
oh, tout simplement FMP... mais c'est un produit commercial sur lequel je n'ai pas la main ! et très bien fait qui plus est, ce serait un énorme boulot de tout refaire ; je veux simplement extraire régulièrement quelques données pour les exploiter à ma sauce.
-- Philippe Manet
Hubert Figuiere <hfiguiere@teaser.fr> wrote:
Solution: migrer la base sur un vrai SGBD. MySQL devrait suffire.
oh, tout simplement FMP... mais c'est un produit commercial sur lequel
je n'ai pas la main ! et très bien fait qui plus est, ce serait un
énorme boulot de tout refaire ; je veux simplement extraire
régulièrement quelques données pour les exploiter à ma sauce.
Solution: migrer la base sur un vrai SGBD. MySQL devrait suffire.
oh, tout simplement FMP... mais c'est un produit commercial sur lequel je n'ai pas la main ! et très bien fait qui plus est, ce serait un énorme boulot de tout refaire ; je veux simplement extraire régulièrement quelques données pour les exploiter à ma sauce.
-- Philippe Manet
benoit.sansspam
manet wrote:
oh, tout simplement FMP... mais c'est un produit commercial sur lequel je n'ai pas la main ! et très bien fait qui plus est, ce serait un énorme boulot de tout refaire ; je veux simplement extraire régulièrement quelques données pour les exploiter à ma sauce.
Tu ne peux pas faire un applescript qui génère ton export ? Tu l'enregistres en appli et tu le lances depuis cron.
Mes deux cents ;-)
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
manet <pmanet@invivo.edu> wrote:
oh, tout simplement FMP... mais c'est un produit commercial sur lequel
je n'ai pas la main ! et très bien fait qui plus est, ce serait un
énorme boulot de tout refaire ; je veux simplement extraire
régulièrement quelques données pour les exploiter à ma sauce.
Tu ne peux pas faire un applescript qui génère ton export ? Tu
l'enregistres en appli et tu le lances depuis cron.
Mes deux cents ;-)
--
Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
oh, tout simplement FMP... mais c'est un produit commercial sur lequel je n'ai pas la main ! et très bien fait qui plus est, ce serait un énorme boulot de tout refaire ; je veux simplement extraire régulièrement quelques données pour les exploiter à ma sauce.
Tu ne peux pas faire un applescript qui génère ton export ? Tu l'enregistres en appli et tu le lances depuis cron.
Mes deux cents ;-)
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
pmanet
Benoit wrote:
Tu ne peux pas faire un applescript qui génère ton export ? Tu l'enregistres en appli et tu le lances depuis cron.
je crois que je vais faire quelque chose de ce genre : Comme ODBC fonctionne bien sous Win, une mini appli FMP sur le beurk, qui se contente d'extraire les données de la base acces avec un script vers un fichier FMP sur un repertoire partagé. Sur le mac, reprise des données avec FMP ; et comme il y a une 15aine de tables, va falloir scripter tout ça gentiment...
sinon, en me renseignant un peu, j'ai vu qu'il semblait exister des drivers ODBC sur mac venant d'openscript, qui n'exigeaietn pas d'avoir le driver correspondant sur le PC pour attaquer une base Access.
Quelqu'un à l'expérience de ce genre de fonctionnement ?
Pour résumer ce que j'ai compris d'ODBC :
une source de données est hébergée sur le serveur, elle est gérée par un SGDB ou équivalent (ici Acces) On veut accéder à ces données depuis un client (ici FMP) pour les enrichir, les exploiter, les pomper, les modifier.
Si on utilise une procédure 1-Tier, il suffit d'avoir un driver ODBC correspondant à Acces sur la machine Cliente.
Si on utilise une procédure Multi-Tier, il faut avoir sur le client et sur le serveur des drivers qui sachent se causer.
Et finalement, il y a sur le client un utilitaire "ODBC configure" qui permet de définir des relations entre tous ces machines et de définir des chemins faciles à réutiliser. Je n'ai pas encore compris quelle cible on devait lui donner : un fichier partagé ou un service ouvert sur le serveur ?
dans mon cas, le driver FMP standard sur macOS ne sait pas causer direct à une base Acces, c'est bien ça ? -- Philippe Manet
Tu ne peux pas faire un applescript qui génère ton export ? Tu
l'enregistres en appli et tu le lances depuis cron.
je crois que je vais faire quelque chose de ce genre :
Comme ODBC fonctionne bien sous Win, une mini appli FMP sur le beurk,
qui se contente d'extraire les données de la base acces avec un script
vers un fichier FMP sur un repertoire partagé.
Sur le mac, reprise des données avec FMP ; et comme il y a une 15aine de
tables, va falloir scripter tout ça gentiment...
sinon, en me renseignant un peu, j'ai vu qu'il semblait exister des
drivers ODBC sur mac venant d'openscript, qui n'exigeaietn pas d'avoir
le driver correspondant sur le PC pour attaquer une base Access.
Quelqu'un à l'expérience de ce genre de fonctionnement ?
Pour résumer ce que j'ai compris d'ODBC :
une source de données est hébergée sur le serveur, elle est gérée par un
SGDB ou équivalent (ici Acces)
On veut accéder à ces données depuis un client (ici FMP) pour les
enrichir, les exploiter, les pomper, les modifier.
Si on utilise une procédure 1-Tier, il suffit d'avoir un driver ODBC
correspondant à Acces sur la machine Cliente.
Si on utilise une procédure Multi-Tier, il faut avoir sur le client et
sur le serveur des drivers qui sachent se causer.
Et finalement, il y a sur le client un utilitaire "ODBC configure" qui
permet de définir des relations entre tous ces machines et de définir
des chemins faciles à réutiliser. Je n'ai pas encore compris quelle
cible on devait lui donner : un fichier partagé ou un service ouvert sur
le serveur ?
dans mon cas, le driver FMP standard sur macOS ne sait pas causer direct
à une base Acces, c'est bien ça ?
--
Philippe Manet
Tu ne peux pas faire un applescript qui génère ton export ? Tu l'enregistres en appli et tu le lances depuis cron.
je crois que je vais faire quelque chose de ce genre : Comme ODBC fonctionne bien sous Win, une mini appli FMP sur le beurk, qui se contente d'extraire les données de la base acces avec un script vers un fichier FMP sur un repertoire partagé. Sur le mac, reprise des données avec FMP ; et comme il y a une 15aine de tables, va falloir scripter tout ça gentiment...
sinon, en me renseignant un peu, j'ai vu qu'il semblait exister des drivers ODBC sur mac venant d'openscript, qui n'exigeaietn pas d'avoir le driver correspondant sur le PC pour attaquer une base Access.
Quelqu'un à l'expérience de ce genre de fonctionnement ?
Pour résumer ce que j'ai compris d'ODBC :
une source de données est hébergée sur le serveur, elle est gérée par un SGDB ou équivalent (ici Acces) On veut accéder à ces données depuis un client (ici FMP) pour les enrichir, les exploiter, les pomper, les modifier.
Si on utilise une procédure 1-Tier, il suffit d'avoir un driver ODBC correspondant à Acces sur la machine Cliente.
Si on utilise une procédure Multi-Tier, il faut avoir sur le client et sur le serveur des drivers qui sachent se causer.
Et finalement, il y a sur le client un utilitaire "ODBC configure" qui permet de définir des relations entre tous ces machines et de définir des chemins faciles à réutiliser. Je n'ai pas encore compris quelle cible on devait lui donner : un fichier partagé ou un service ouvert sur le serveur ?
dans mon cas, le driver FMP standard sur macOS ne sait pas causer direct à une base Acces, c'est bien ça ? -- Philippe Manet
benoit.sansspam
manet wrote:
Si on utilise une procédure 1-Tier, il suffit d'avoir un driver ODBC correspondant à Acces sur la machine Cliente.
Si on utilise une procédure Multi-Tier, il faut avoir sur le client et sur le serveur des drivers qui sachent se causer.
De ce que je connais et de ce que j'utilise d'ODBC (vers un AS400) il y a deux solutions :
- soit la solution propriétaire du concepteur de la bdd qui permet à des clients de taper directement dans la base.
- soit la solution qui passe par un serveur ODBC qui est un intermédiaire entre le/les clients et le/les bdd. Cette solution est souvent plus ouverte car le serveur ODBC accepte des clients ODBC de différentes plateformes (cf ex. qui suit).
Mes requêtes ODBC sur l'AS400 n'ayant lieu qu'une fois par trimestre un coup de vurtual PC suffit pour lancer le client ODBC livré avec l'AS400 et générer les extractions de la base nécessaires au boulot (imports dans Excel Mac pour retraitement...). Les besoins hebdomadaires sont générées automatiquement, toutes les nuits, sur l'AS400 par la base (le créateur de la base a eu le droit à ça dans son cahier des charges) et un script les récupère via ftp pour les incorporer dans Excel.
voili voilou,
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
manet <pmanet@invivo.edu> wrote:
Si on utilise une procédure 1-Tier, il suffit d'avoir un driver ODBC
correspondant à Acces sur la machine Cliente.
Si on utilise une procédure Multi-Tier, il faut avoir sur le client et
sur le serveur des drivers qui sachent se causer.
De ce que je connais et de ce que j'utilise d'ODBC (vers un AS400) il y
a deux solutions :
- soit la solution propriétaire du concepteur de la bdd qui permet à des
clients de taper directement dans la base.
- soit la solution qui passe par un serveur ODBC qui est un
intermédiaire entre le/les clients et le/les bdd. Cette solution est
souvent plus ouverte car le serveur ODBC accepte des clients ODBC de
différentes plateformes (cf ex. qui suit).
Mes requêtes ODBC sur l'AS400 n'ayant lieu qu'une fois par trimestre un
coup de vurtual PC suffit pour lancer le client ODBC livré avec l'AS400
et générer les extractions de la base nécessaires au boulot (imports
dans Excel Mac pour retraitement...). Les besoins hebdomadaires sont
générées automatiquement, toutes les nuits, sur l'AS400 par la base (le
créateur de la base a eu le droit à ça dans son cahier des charges) et
un script les récupère via ftp pour les incorporer dans Excel.
voili voilou,
--
Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Si on utilise une procédure 1-Tier, il suffit d'avoir un driver ODBC correspondant à Acces sur la machine Cliente.
Si on utilise une procédure Multi-Tier, il faut avoir sur le client et sur le serveur des drivers qui sachent se causer.
De ce que je connais et de ce que j'utilise d'ODBC (vers un AS400) il y a deux solutions :
- soit la solution propriétaire du concepteur de la bdd qui permet à des clients de taper directement dans la base.
- soit la solution qui passe par un serveur ODBC qui est un intermédiaire entre le/les clients et le/les bdd. Cette solution est souvent plus ouverte car le serveur ODBC accepte des clients ODBC de différentes plateformes (cf ex. qui suit).
Mes requêtes ODBC sur l'AS400 n'ayant lieu qu'une fois par trimestre un coup de vurtual PC suffit pour lancer le client ODBC livré avec l'AS400 et générer les extractions de la base nécessaires au boulot (imports dans Excel Mac pour retraitement...). Les besoins hebdomadaires sont générées automatiquement, toutes les nuits, sur l'AS400 par la base (le créateur de la base a eu le droit à ça dans son cahier des charges) et un script les récupère via ftp pour les incorporer dans Excel.
voili voilou,
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
