Jump to content
  • 0
RSCP

Tri Dans Fmp De Données Issues De Base Mysql

Question

Bonjour toutes/tous,

Je débute en MySQL, alors un peu d'indulgence svp :blush:

Soit une base FileMaker Pro contenant deux tables MySQL

Deux des écrans affichent en liste les données de chaque table MySQL.

Tout fonctionne correctement (ajout, suppression, modification, recherche...) SAUF les tris qui sont d'une extrême lenteur.

Enfin, pas tout à fait…

Le premier tri est TRÈS lent. Après, chaque nouveau tri semble normal.

Mon premier réflexe est de chercher du côté de l'index.

J'ai donc ajouté un index dans la base MySQL pour chaque rubrique susceptible de faire l'objet d'un tri dans mes deux écrans liste.

Cela ne peut être réalisé que via mon outil de gestion MySQL (Navicat en l'occurrence) puisque FMP ne le permet pas.

Y a-t-il autre chose à faire que de créer les index ?

Une commande mySQL à lancer à l'ouverture de la base FMP ?

Si oui, comment procéder ?

Je ne constate en effet aucune différence "avant" et "après" l'ajout d'index : le premier lancement d'un tri est toujours aussi long.

Merci d'avance à ceux qui voudront bien se pencher sur mon problème.

Raymond Studer.

Share this post


Link to post
Share on other sites

9 answers to this question

Recommended Posts

  • 0

Pour votre problème actuel de lenteur de tri, on dirait que ça vient du fait que FM doit mettre en mémoire cache des blocs d'enrégistrements provenants de la source SQL externe. Avec ou sans index dans Sql, je pense que ça ne changera rien. De la façon dont FM est programmé, sauf erreur, c'est SQL qui contient les données et c'est FM, à l'interne, qui s'occupe des tris.

Est-ce que votre BD FileMaker est hébergée sur un serveur FileMaker? Si oui, est-ce qu'il s'agit du même serveur que le serveur MySql??

Ce n'est pas très conforme comme déploiement, mais j'ai constaté une amélioration marquée de toutes les performances quand les 2 services (FMS et MySql) sont sur le même serveur...

Share this post


Link to post
Share on other sites
  • 0
Pour votre problème actuel de lenteur de tri, on dirait que ça vient du fait que FM doit mettre en mémoire cache des blocs d'enrégistrements provenants de la source SQL externe. Avec ou sans index dans Sql, je pense que ça ne changera rien. De la façon dont FM est programmé, sauf erreur, c'est SQL qui contient les données et c'est FM, à l'interne, qui s'occupe des tris.

Est-ce que votre BD FileMaker est hébergée sur un serveur FileMaker? Si oui, est-ce qu'il s'agit du même serveur que le serveur MySql??

Ce n'est pas très conforme comme déploiement, mais j'ai constaté une amélioration marquée de toutes les performances quand les 2 services (FMS et MySql) sont sur le même serveur...

Bonjour,

Grand merci pour votre réponse même si cela n'est pas très encourageant puisque correspondant à une limitation de FMP.

La base de données FMP n'est pas hébergée mais utilisée sur un seul poste.

La base de données MySQL est sur un serveur distant.

Je n'ai donc aucune possibilité d'optimisation de ce côté.

Merci encore pour la réponse.

Raymond Studer.

Share this post


Link to post
Share on other sites
  • 0

je crois qu'il faut vraiment recommander de ne pas bâtir de modèle sur les tables ESS, c'est un piège à c... si je puis dire (je suis tombé dedans...)

Ne surtout pas tenter de faire de FileMaker un front end pour SQL, ça ne marche tout simplement pas.

Share this post


Link to post
Share on other sites
  • 0

Fabrice, peux-tu préciser ce que tu entends par "ça ne marche tout simplement pas" ? Pour ma part, les retours d'expériences en la matière sont excellent et permettent, entre autres, des connexions web via PHP sans l'usine à gaz proposée par FileMaker. Il est vrai que la config ici proposée est loin d'être idéale et, comme Gaston le mentionne, dans tous les cas que je connaisse, les 2 services sont sur la même bécanne.

Je sais que FileMaker préconise de ne pas utiliser FMP comme front-end de MySQL, mais sans expliquer pourquoi, ni en démontrant clairement que ça ne marche pas. Et en fait, ça marche... ;) Sous Windows, bien entendu. Pas de feed-back sous Mac.

Christian

Share this post


Link to post
Share on other sites
  • 0

Salut Christian,

1. Pas de rafraîchissement instantanné, le processus de rafraîchissementS périodiques peut donc conduire à des vues qui ne sont pas le strict reflet de la réalité des données

2. Pas de véritable blocage d'enregistrement, plusieurs utilisateurs peuvent modifier le même enregistrement. La règle du First Out s'applique pour déterminer celui qui sera validé

3. Problèmes de type-casting, le nombre de type de données proposé par FileMaker est inférieur à celui proposé ailleurs dans les schémas SQL

4. Tris lents, normal on n'utilise pas SQL. On 'importe' le lot à trier et FileMaker accomplit sa tâche ensuite. Pour les recherches sur des rubriques non mémorisées, mieux vaut les empêcher. Par contre, les recherches, elles, sont déléguées à SQL. On n'a plus à faire au même processus donc.

5. Pas d'action sur les schémas SQL

...

La liste peut être allongée et explique pourquoi d'autres plateformes sont suceptibles de devenir des front-end mais assurément pas FileMaker. On trouvera son chemin et plein d'utilités aux sources ESS ( notamment des données statiques, ou des mises à jour unilatérales, etc ), mais pas pour bâtir un front-end. FileMaker a donc proposé une ouverture vers de nouvelles sources, une mini intégration, mais se défend bien ( fort heureusement ) de vouloir changer de marché.

Ceux qui veulent comparer Filemaker aux autres plateformes spécifiquement dessinées pour n'intégrer que des sources SQL ( Alpha 5 par exemple joue pas mal avec ça ) arrivent nécessairement à des comparatifs biaisés. Il faut s'en méfier, et accepter de défendre la position de FileMaker. La source de données privilégiée, c'est FileMaker et son moteur.

Share this post


Link to post
Share on other sites
  • 0

Ooops...

Il semble que cette info m'ait échappé...

J'avais compris au contraire que FMP convenait pour ce type d'usage : front end lié à un site dynamique.

J'ai deux offres en cours, en dehors du développement que je mentionnais et qui est fini (à part le problème de lenteur du premier tri du jour), qui sont relatives à ce type d'utilisation.

Alors, si ce n'est pas le cas... no comment :wacko:

Si l'intégration MySQL / FMP est un leurre, n'est-ce qu'un argument marketing pour mieux le vendre.

Ou bien, y a-t-il certains cas où on peut l'utiliser et d'autres non ?

Merci de partager vos expériences.

Raymond Studer.

Share this post


Link to post
Share on other sites
  • 0

Bonsoir,

Non, ce n'est pas un leurre.

Il s'agit bien de faciliter l'intégration de nos solutions FileMaker dans un système d'informations disposant d'autres sources de données.

Il ne s'agit pas de centraliser toutes les sources de données au travers d'une interface dessinée avec FileMaker. FileMaker n'est pas un RAD destiné à cela.

Je n'y vois aucun faux language, ni leurre, juste peut être quelque enthousiasme à contrôler, et la nécessité de bien prendre tout ceci en considération. L'ouverture aux sources SQL via l'ESS a peut-être trompé certains développeurs trop heureux de penser qu'ils pouvaient par ce biais se passer de connaissances du language SQL.

Mais on est toujours vite rattrapé par le dicton d'Yvan. le bon outil pour le bon projet.

Au fait, FileMaker peut être u front-end SQL quand même, mais pas au travers de l'ESS ;)

Share this post


Link to post
Share on other sites
  • 0
front end lié à un site dynamique

Précisions pour le Web; FM server constitue un bon backend (entrepôt de données) pour des applications Web. Bien qu'imparfait, l'API PHP offre de bonnes performances même pour des besoins relativement grands. La sécurité intégrée dans FMS est appliquée à toutes les technologies servies ce qui inclut le client-serveur, la publication instantanée, le php, le xsl et les connections xDBC. Donc, moins de soucis à se faire quand on programme dans PHP par exemple. La possibilité de lancer des scripts (commandes limitées) du côté serveur est aussi un gros avantage.

Mais au final, les données servies, sécurisées et manipulées sont dans FM et non pas transitées depuis un Sql.

Share this post


Link to post
Share on other sites
  • 0

Bonsoir Ugo,

Merci pour tes commentaires.

Je suis de plus en plus confronté à des demandes du style :

- un site web (créé par d'autres)

- quelques données accessibles au travers de ce site (inscriptions, recherches données après authentification, …)

- lesquelles données sont stockées dans une base MySQL parce que les développeurs web maîtrisent cet outil

- un backoffice qui permette d'accéder à ces données (en plus d'autres qui sont du FMP pur et dur et qui ne nécessitent pas d'être accessibles depuis le web), que j'aimerais développer sous FMP pour des tas de raisons, ne serait que parce que je l'utilise depuis FileMaker II en 88 :rolleyes:

Si FMP n'est pas l'outil adéquat, que recommandes-tu pour répondre à ce type de problématique ?

Merci pour ton feedback.

Raymond.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...