fida_laurent

Si tu as tout mis en chemin relatif, je ne pense pas qu'il y aura de problèmes. Si en revanche, tu as tout mis en chemin absolu, j'ai bien peur qu'il faille revoir tous les scripts à moins que l'on puisse automatiser tout cela. ++

J'ai manisfestement mal cherché dans les archives, méa culpa. Merci à toi Thierry pour ta réponse. ++ PS : si l'admin peut effacer mon post, ça évitera de faire doublon inutilement.

Je suis allé trop vite pour mon premier post et suis totalement passé à coté de l'évidence même. J'ai bien évidement fait un autolien sur la rubrique calcul. Ensuite, je n'arrive pas à faire en sorte de controler l'unicité de la fiche "personne". Quelqu'un pourrait il éclairer ma lanterne ? Merci par avance.

Bonjour, Je souhaite qu'on ne puisse pas inscrire deux fois la même personne sans que l'utilisateur n'ait à vérifier que la personne est déjà répertoriée ou pas. Le "problème" est que je ne souhaite pas faire ce controle de doublon par un script. Pour cela, j'ai une rubrique "controle_doublon" de type calcul : nom & prenom & date_de_naissance. Je souhaitais la mettre "unique" (ce qui aurait résolu mon problème) mais ce n'est pas possible sur une rubrique de type calcul. Quelqu'un aurait-il une idée ? C'est certainement évident, mais là je ne vois pas. Merci par avance. ++

Moi je ferais comme suit : - un mot de passe par utilisateur. - le mot de passe est "limité" en consultation et modification par la valeur d'une rubrique controle. Exemple : mot de passe = "MDP" auquel j'associe une limitation en consultation de la sorte : controle="tartanpion". Résultat : seules les fiches qui ont comme valeur "tartanpion" dans la rubrique controle pourront être consultées par l'utilisateur dont le mot de passe est "MDP". ++

PIROG, j'ai rencontré les mêmes symptomes que toi : - FMP Server 5.5 qui partage ses bases. - FMP Pro Un client, en se connectant par FMP Pro à FMP Server, partageait ses bases via le réseau. Lorsqu'un autre client se connectait, il se trompait parfois de base et allait éditer celles du 1er utilisateur au lieu de prendre les bases originales sur FMP Server. Résultat : c'est la même base, pourtant les modifications n'étaient pas prises en compte. ++

Voila à quoi ça sert d'imprimer en PDF...c'était en réponse à cette question ci. ++

Je pense que tel Sherlock Holmes, dans un tel cas il faut envisager toutes les possibilités et écarter celles qui sont le moins probables. Pour cela, ce que je ferais (je ne sais pas si tu l'as déjà fait) : - Vérification que ce problème existe avec une base de test nouvellement créée. - Vérification que ce problème existe avec une copie de la base en question. - Vérification que ce problème existe avec la base en question partagée sur un autre ordinateur. - Vérification que ce problème existe avec la base en question accédée par un autre utilisateur ou à partir d'un autre poste. Je pens

En ce qui me concerne j'ai ici un seul CD FMP Pro 6 et 10 licences representées par un bout de papier. Si je voulais, je pourrais installer en 20 ou même 30, ce qui n'est pas à conseiller bien entendu. Je dis ça car je pense que tu peux prendre des LICENCES FMP7 c'est à dire un bout de papier pour pouvoir installer FMP6. J'imagine que ce n'est pas illégal, le tout est de payer Filemaker pour l'utilisation de ses logiciels. ++

Ne peux tu pas les imprimer en pdf ? Ensuite, tu peux toujours les manipuler, les modifier et les mettre à la suite. ++

Bonjour, A ma connaissance, il faut modifier manuellement la défintion de rubrique. Ou alors, tu définies une rubrique globale à laquelle tu donnes la valeur du nombre de fiches dans la base. Ensuite au lieu de mettre une rubrique automatique, tu fais en sorte qu'elle prenne sa valeur de la globale. Moi je ferais comme ça, ce n'est peut pas le plus simple mais ça marche. ++

Merci pour les tuyaux Olivier. ++

Robert, Si fx.php utilise le WebCompanion et indirectement le cDML, il doit certainement reprendre les mêmes défauts non ? Pour moi, le principal défaut du WebCompanion est qu'il traite les requêtes de façon séquentielle c'est à dire l'une après l'autre, je trouve ça très gênant pour la vitesse d'affichage des pages et les ressources utilisées sur le serveur car dans ma base il y a beaucoup de tri à faire pour associer certains groupes de fiches (entre 40 et 2000) par utilisateur. En ce qui concerne mon sujet, un utilisateur doit vérifier qu'une personne n'est pas déjà inscrite dans ma base s

Merci pour vos réponses. J'ai fini de potasser Java (du moins mon premier bouquin) et je pense que bien que PHP étant très puissant et très simple à mettre en oeuvre, je vais choisir Java, et ceci pour les raisons suivante : - Langage de programmation au sens propre du terme - Très agréable à programmer (argument totallement subjectif je le concois). - Possibilité de faire des applications sans avoir un serveur web pour traiter les requêtes - Extensible à d'autres bases de données simplement (en changeant le connecteur JDBC) Si quelqu'un a des commentaires à faire, je suis toujours ouver

Merci de ton conseil, j'avais cru noté que tu étais un adepte de fx.php