Marsau

Inderdaad, heb ik mij ook afgevraagd. Misschien ontdekken we nog een interessant gebruiksperspectief.

Thanks, Andries. Directe interactie met het Filemaker systeem is niet nodig. Als de scanner bestandjes kan wegschrijven naar een bepaalde folder die de server uitleest, dan zijn we er al. Leek zo eenvoudig.

Een beetje off topic wellicht. Wil voor een klant een barcode scanner (ehhh mobile computer!) implementeren, om magazijn-posities te corrigeren. Klant heeft voortvarend een Datalogic Memor X3 aangeschaft, ter vervanging van oudere scanners. Aan Filemaker zijde geen probleem (vooralsnog), maar hoe krijg je dat F#!?* ding operationeel? Aan handleiding etc geen gebrek, maar geen woord over een fatsoenlijke deployment. Is er enige ervaring onder de geachte confrères?

Nee, helaas niet. Een server, en het betreffende schedule is verwijderd.

Beste mensen, Heb onlangs een script schedule verwijderd, en ook het bestand waarop het schedule betrekking heeft. Nu blijkt het schedule gewoon nog steeds door FileMaker Server uitgevoerd te worden. Ik stel dat vast omdat ik notificaties blijf ontvangen waarin het vastlopen wordt gemeld. Heb via de CLI script engine herstart, de console en ook de database server. No luck: de mails blijven komen. Raar niet? hebben jullie een idee?

https://www.fmsummit.info/doc

Even uit de losse pols: een andere mogelijkheid is gebruik van een plug-in, zoals Scribe of MBS, om de aangeleverde xls te verwerken. Voordeel is dat je per regel alle businesslogica zou kunnen scripten.

Probeer eens benadering zonder plugin en zonder fonts. Maakt je applicatie apparaat en platform onafhankelijk.

Hoe genereer je je barcodes? Ik vermoed dat je barcode font gebruikt. In dat geval zou je kunnen overwegen om een generator te gebruiken die png-barcodes genereert die je in containers kan opslaan. Die van Geist is bijvoorbeeld super.

Geen ervaring, maar het ziet er straightforward uit, afgaande op de documentatie van de API. Het moet kunnen. Ook om de link in de factuur mee te nemen, natuurlijk.

Ik zou ook ongeveer aan deze aanpak denken. Met regels van gelijke hoogte is het gemakkelijker (en zou de routine ook korter zijn). Maar... Welk probleem wil je oplossen met de opslag van paginanummers in records? Is toch ook wel hele dynamische / contextueel bepaalde informatie...

Moeten we testen..

Probleem is naar alle waarschijnlijkheid opgelost. Dank voor deze informatie! Fantastisch dat iemand deze oorzaak heeft weten te vinden. Het betreft dus inderdaad de custom menu's. Een naald in een hooiberg, en een ook nog eens een hele destructieve. Mijn hypothese: menu's aangemaakt met een voorgaande versie van Filemaker zijn vatbaar voor deze corruptie, en kunnen vervolgens problemen veroorzaken onder Filemaker 17 i.c.m. Windows. Je moet er maar achter komen... Ik heb de menu's even disabled en bouw ze opnieuw binnen FM17 op. Dank voor jullie aandacht!

Dank je. Heel scherp gevonden: de situatie lijkt bijna identiek. Ik ga het zsm proberen. Tweaken van de server heeft overigens niets opgeleverd. M

Zeker. Er is nog geen oplossing. Vastgesteld: het betreft alleen (sommige) Windows computers, in relatie tot een productie-server. Connectie van dezelfde machine met een test-server levert geen problemen op (maar die wordt ook minder belast met aantal clients). Op basis van discussies in de Filemaker Community (https://community.filemaker.com/thread/187019)zien we: - mogelijk conflict met een Windows update 1803? - Office 365 conflict met laatste update Moet dit nog onderzoeken. Symptomen: a. Of: werkgeheugen client loopt vol na bepaalde acties (zoeken, bestand openen etc), machine hangt, na een paar minuten hervatten. Gedurende deze tijd is er geen netwerkverkeer. b. Of: volledige crash: harde reset nodig. Server lijkt geen krimp te geven. Geheugen, netwerk, opslag binnen alle perken. Geen rare pieken.

Hi Menno, ik heb dezelfde ervaring bij andere migraties, maar in dit specifieke geval... Ik realiseer mij dat er vele variabelen zijn die voor problemen kunnen zorgen. Om het even plat te slaan: Oude situatie: FMS 14, clients 13 t/m 16. => Geen noemenswaardige problemen. Nieuwe situatie: alles op 17, alle overige variabelen ongewijzigd => Dikke stroop. Ik heb een flinke slag weten te slaan door de lokale client cache - hoefden we nooit aan te raken; waren het bestaan van de instelling vergeten - op te hogen naar 512 mb. Geinspireerd door deze excellente handleiding: https://deskspace.com/understanding_filemaker_server_performance_introduction.html Echter: situatie van eindeloos wachten (door gebruiker geïnterpreteerd als "vastlopen") blijft zich voordoen. Vooral na snel schakelen tussen een stevige lijstweergave, beperken set > hoofdmenu > beperken set => valley of death Moeten we dieper graven? groetjes, Mars BTW, ja, dit jaar weer van de partij

Beste mensen, Afgelopen week bij een klant alle servers en clients gemigreerd naar Filemaker 17, na een periode van testen van onze 'ecologie' in een separate omgeving. Na het doorvoeren van de update ervaren we onacceptabele traagheid op bepaalde machines en/of bij bepaalde handelingen. Processen die voorheen redelijk verliepen kunnen nu zelfs aanleiding geven om Filemaker af te breken, omdat ze (schijnbaar?) vastlopen. Server cache verhoogd via de CLI. Maar bij vastlopende clients zie ik verder geen netwerkverkeer, waaruit ik meen af te mogen leiden dat het ook een lokaal probleem kan zijn. Ben dus aan het speuren, ben benieuwd of jullie zinnige tips of aanwijzingen hebben. FM(S)17 zou toch een quantum leap voorwaards moeten zijn, niet? Alvast dank…

Het is een beetje verwarrend om met zo'n goed geïnformeerde Pipo te spreken Dank voor de tip. Wellicht is het een leuk idee om die logs direct in een Filemaker bestand te verwerken, of krijg je dan het Droste-effect Wederom ook een bevestiging van mijn zijde vwb het server side scripten met externe tabellen: het werkt echt. Voor wat betreft 'platte' data-uitwisseling in ieder geval. Remote triggeren van scripts was (nog) niet mijn doel.

Sorry voor dit late antwoord, Peter. Het is een tijdje buiten mijn aandacht geweest. De robot doet zijn werk op zich prima, maar vergt voortdurend aandacht. Ik heb het vraagstuk niet opgelost: ik heb de ervaring dat het werkt (ook jouw statement), en dat het niet werkt (Menno), en begrijp niet wat hier de bepalende factor is. Op dit moment weer een aantal zaken werkend gekregen, maar kan niet aanwijzen wat ik anders heb gedaan. Server side scripting is idd een grijs gebied. Mars

Met deze benadering laat je wellicht kansen liggen. Ik zou proberen projecten in één bestand (tabel) te krijgen. Je zult dan veel meer controle mogelijkheden krijgen.

Mooie handleiding, Menno. Ik stoeide vandaag met een andere benadering, waarbij je de tool flexibel kan inzetten. Vrij doorvertaald aan de hand van tooltjes van bijv Soliant Consulting - de tool opslaan in een container. - voor source en de kloon ook een aparte container, waarin je de bestandsverwijzingen opslaat - aparte veldjes voor alle opties. Als je de migratie start, exporteer je de tool op een bepaalde plek (desnoods de tempory folder) en laat je het het resultaat wegschrijven naar een logveldje. Nog niet geheel werkend, want op een of andere manier lijkt de tool bij de export gecorrumpeerd te raken, maar de commandline, die werkt.

Helaas maar één opmaak per object, zover ik weet. Je zou de opmaak van de prijs kunnen fixeren in een apart calculatieveldje. Zou je ook een custom functie voor kunnen maken ( valutabedrag weergeven, valuta teken en altijd 2 decimalen oid)...

Geweldig Menno. Jammer dat we geen 'likes' kunnen geven in dit forum. :-)

Yep! FM Advanced is zelfs niet eens vereist.

Nee, Peter. Nog steeds de hypothese dat dit bij FMS ≤ 14 niet werkt, zoals ook door jou bevestigd. Ondertussen doet een robot de noodzakelijke syncs, waardoor de druk om een oplossing te vinden er niet bepaald is. Klant wil nu niet investeren in een upgrade naar de laatste versie