fabriceN

Avec Claris, dis bonnes vacances à Fabrice

Encore plus simple (ne demande pas de nommer les objets) : ajouter une rubrique globale, qu'on définit selon le paramètre, et c'est toujours celle-ci qu'on exporte.

La réponse est la même que dans ce sketch. Mais pour 15 utilisateurs, s'il ne s'agit pas d'une application monstre, en général ça suffit.

Tout pareil que Florian. En prenant en compte le fait que vous avez des salariés à distance (qui ont aussi besoin d'un bon accès), et que le coût d'un serveur local + électricité + solution de backup externe + temps de maintenance + monitoring + risque de longue interruption en cas de problème… vs un hébergement dernier cri pour moins de 80€/mois pour 15 utilisateurs. En ce qui me concerne le choix est vite fait, mais il existe des cas particuliers (zone avec mauvaise couverture réseau, application mal optimisée…)

D'après vos photos d'écran vous êtes en FileMaker 16, incompatible avec FileMaker Cloud. FileMaker Cloud utilise une version bridée de FileMaker Server 19, il faut donc au minimum FileMaker Pro/Go 18 pour s'y connecter.

Le problème fondamental est la confusion entre un identifiant et un numéro de référence. Un identifiant ne doit avoir aucune signification, ou du moins aucune qui soit nécessaire au fonctionnement. Il est tout à fait possible, pour un même document, d'avoir un identifiant primaire, un numéro de document interne, un sous-numéro, un numéro de client, un numéro de référence du client, un numéro de dossier, un numéro de bon de commande client… etc (oui oui, tout ça sur le même document, et c'est sans compter sur le numéro de téléphone, le SIRET et l'âge du capitaine !) L'identifiant d'un enregistrement dans une base de données est simplement ce qui va permettre à la base de données de s'y retrouver. Aucun autre usage. Et donc ici votre problème c'est que la base de données utilise un numéro de document comme identifiant. Si ça n'était pas le cas vous vous ficheriez comme de votre première chemise que l'identifiant soit un UUID, non incrémentable donc.

clairement le fichier d'origine n'a pas besoin de conversion. C'est le fichier original qui a un problème. Je veux bien essayer ici. si vous me l'envoyez

Quelle est l'extension du fichier d'origine ? N'est-ce pas un fichier au sein d'un runtime ?

ah ok. Le but dont je me souvenais était pour la première version de PSoS en 14.

oui je crois mais le problème c'est l'authentification. Ou alors peut être en exécutant un script de l'autre fichier. (ma mémoire a des limites, de plus en plus)

Problème corrigé en 14.2, il y a 8 ans De mémoire, si le fichier est préalablement ouvert explicitement par le script, alors ça fonctionne.

C'est peut être lié à une micro coupure de la connexion ? Votre hébergeur permet-il d'uploader les fichiers en ftp ?

On peut aussi gérer ça avec un déclencheur de script (mais ça ne dispense pas de l'auto-entrée pour les imports, définir rubrique…) caracteresInterdits.fmp12

ExecuteSQL est exécutée côté client quand l'enregistrement est ouvert, sur serveur s'il est validé.

aaaaahhh ! daaaaacccord !