Jump to content

hans erik

Leden
  • Content Count

    812
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Vraagje aan de experts. Als je via de dataAPI een connectie maakt, hoe ziet FileMaker Server dat dan? Als een soort WebDirect sessie? Je kunt bijv niet direct een PDF (on server) aanmaken, maar via een PSoS kun je wel weer van alles laten uitvoeren.
  2. Zal ik ook even naar kijken. Heb inmiddels de laatste upgrade geïnstalleerd maar het probleem bljift zich voordoen, en het treedt altijd op bij het aanmaken van een PDF (op de server). Dus ik denk dat daar een fout in zit. Ga nu het PDF script naar lokaal halen en kijk of het over is. Wat betreft het aantal sessies: wat bedoelt FMI precies met een sessie? Stel dat je een script on Server uitvoert en dat script roept 7 subscripts aan, zijn dat dan 8 sessies of is het er 1? Het gaat allemaal zo snel dat je in de console die teller echt niet ziet verspringen, en de log is zoals gebruikelijk vrij nietszeggend. Mijn gevoel zegt me dat het 1 sessie is (ik heb geen scripts die in een soort oneindige loop terecht kunnen komen, de scriptstack wordt ook nooit langer dan 4).
  3. Zijn de foto's in het originele bestand opgeslagen als Remote Container of in het bestand zelf? En zijn ze encrypted? En als het om een import gaat t.b.v. een nieuwe versie van hetzelfde bestand, zou je kunnen overwegen om de containervelden in een apart bestand onder te brengen met een link op UUID, dan hoef je de hele import niet te doen. Matt Petrowsky had daar onlangs een goede pocast over: https://www.filemakermagazine.com/videos/optimized-container-storage
  4. Dank voor je suggestie. Dat van die insert from URL had ik niet aan gedacht, ga ik zeker proberen. Ik gebruik de plugin ook om HTML mail te versturen en omdat het uiteindelijk ook vanuit WebDirect moet gaan werken vrees ik dat ik hem toch nodig zal hebben. Maar ook: het is een raar probleem omdat ik vermoed dat bepaalde scriptstappen de queue in de war sturen. Het lastige is alleen dat nergens uit te lezen valt wat de werkelijke staat van die queue is. Wim de Corte suggereert dat het een performance probleem is (16GByte RAM?). Ik maak een logentry op bepaalde plaatsen in de scripts, ondermeer nadat de plugin wordt aangeroepen. Is dat dan succesvol dan zie je dat in de log. En elke PSoS registreert een start en een stop. Ontbreekt de stop dan weet je welk script en gebruiker de eerste is die 'hangt'. En je weet welke scriptstap als laatste succesvol was. Het probleem lijkt nu uit de Save Records as PDF te komen... Dus niet uit de plugin, maar zeker weet je dat natuurlijk nooit. NB sommige gebruikers draaien FMP vanaf een soort Cytrix achtige omgeving. De PDF heb ik naar PSoS verplaatst omdat het gebruik van Calibri op die werkstations de PDf ondersteboven gooide. Heel vreemd: de content bevatte tekens met afwijkende metrics denk ik, en dat resulteert in een volstrekt door de war gegooide PDF! Dat probleem bleef op de server ook terugkomen, en verdween pas toen ik de rapporten in Arial opmaakte(!), Maar het zou dus in theorie aan de inhoud van de PDF kunnen liggen?
  5. Ik heb een FMdatabase (Windows Server 2016) onlangs overgezet van FMS 16 naar FMS 17.0.3.324 Sinds die tijd loopt de script engine van tijd tot tijd vast. - ik gebruik geen Scheduled scripts, alleen PSoS. - het gaat om 2 scripts. Eén lang complex script dat veel subscripts aanroept maar nooit in een loop verstrikt kan raken. Dat script loopt ca 6 seconden op de server. Een ander script maakt een PDF aan, schrijft soms meerdere rapporten naar dezelfde PDF, en maakt gebruik van Base Elements 4.0.3 om de PDF uit de documentsfolder in een containerveld te importeren (daarna wordt de PDF verwijderd om de zaak opgeruimd te houden). - de scripts hebben altijd als voorwaarde 'wait for completion'. Als de FMSE vastloopt, resulteert dat in een strandballetje. Een volgend script wordt gestart, maar komt nooit tot een einde. Heb al op de FM community gekeken, en ik ben niet de enige. Maar waar het precies door veroorzaakt wordt is me niet duidelijk. Onder FMS16 kwam dit nooit voor. Op de MacOS server lijkt het ook niet voor te komen. Ik heb op verschillende plaatsen in de scripts logstappen tussengevoegd met een commit, zodat ik kan zien wat er uitgevoerd is en wat niet. Het lijkt er niet op dat het aan de plugin ligt, die doet keurig zijn werk, maar eerder dat van tijd tot tijd een PSoS script niet 'afgemeld' wordt en voor de server dus blijft 'hangen'. Als dat 25 keer gebeurt, worden alle volgende scripts 'pending'. Tussen twee 'crashes' worden tussen de 100 en 160 PSoS scripts uitgevoerd, maar elk script kan dus meerdere subscripts aanroepen. De reset doe ik in zo'n geval via de CLI, fmsadmin STOP FMSE en fmsadmin START FMSE. De gebruikers die op een script zitten te wachten krijgen dan een melding dat het script niet kon uitgevoerd. In het event log zie ik echter geen rare dingen gebeuren op het moment van vastlopen, vandaar dat ik mijn eigen logging toegevoegd heb. NB als je direct na de restart van de FMSE het script opnieuw start krijg je een foutmelding dat het aantal gelijktijdige script (25) overschreden is. Na een minuut ofzo accepteert ie weer nieuwe scripts. Iemand soortgelijke ervaringen?
  6. Nou ja, niet 100% betrouwbaar. Je kunt altijd alle logrecords opvragen die aan bepaalde criteria voldoen. Als een gebruiker aanlogt, maakt ie een 'login' record aan. Logt ie uit (via een knop of met een trigger op het sluiten vh laatste venster), dan wordt een loguit record aangemaakt. Lastig is iemand die gewoon zijn pc uitzet. Dan krijg je die trigger niet. En ook een webdirect client geeft wel een login maar niet altijd een loguit. Maar je ziet natuurlijk wel wie er de afgelopen x minuten actief is geweest.
  7. Mijn oplossing is denk ik toch iets anders dan die van Menno of Mars. Ik heb het als volgt ingeregeld: - Gebruiker A logt in met account XXX, krijgt een UUID als sessionID. - Bij openen vh projectscherm vult een script automatisch een global veld met ‘active XXX’. Via een relatie op sessionID maakt hij een record aan in de logfile met een automatische timestamp_modification - Bij elke navigatieactie die ik wil loggen werkt het script de logrecord even bij. Dus elke keer verspringt de timestamp_modification in de logrecord. Als gebruiker B ook inlogt met XXX krijgt ie een andere sessionID, en maakt een andere logrecord aan. Op dat moment zijn er 2 logrecords met dezelfde status ‘active XXX’, maar elk met een eigen sessionID en timestamp. - als een van beide gebruikers iets doet, bijv switcht van tabpanel oid, wordt de check gedaan: - een tweede global field heeft een timestamp en via een relatie op ‘active XXX’ en de timestamp_modification (global_timestamp < timestamp_modification) wordt gekeken of er al een recentere logentry is met dezelfde status. - zoniet => prima, zo ja => melding. - en uiteraard wordt daarna de logrecord bijgewerkt, gevolgd door een update van de global_timestamp. Doordat je alleen signaleert als iemand anders een recentere logentry heeft, sluit je gelijk uit dat een sessie per abuis niet goed is afgemeld. Je hoeft dus geen oude meuk op te ruimen….
  8. Ik gebruik mijn 'tracking' ook om te signaleren of gebruikers 2x ingelogd zijn met hetzelfde ID. Dat werkt doordat ik bij sommige navigatiestappen (bijv het wisselen van een layout of tabpanel) een check doe op het aantal SessionID's dat dezelfde status heeft (dwz combinatie van account en status). De check is dan door een relatie op timestamp toe te voegen. Als er 2 gebruikers actief zijn met dezelfde login, spelen ze qua 'timestamp' als het ware 'haasje over' je krijgt dus niet voortdurend een waarschuwing, maar alleen wanneer de ander een latere timestamp heeft dan jij. Op die manier hoef ook geen oude records op te ruimen: die blijven immers in het verleden hangen. De timestamp in de logfile wordt bijgewerkt met de sessionID.
  9. Ik gebruik de oplossing dit jij ook hebt uitgevogeld, Mars. De gebruiker logt aan en krijgt een $$sessionID (= UUID) en maakt een logrecord aan met een status. Die status wordt bij bepaalde activiteiten telkens bijgewerkt (d.w.z. de timestamp). Lastig is alleen dat niet iedereen 'netjes' uitlogt. Dus je moet ook kijken naar de datum ofzo.
  10. Ik ben wel geïnteresseerd in de resultaten hiervan. Is er niet een algemeen toepasbare XSLT van die camt.053 voor FileMaker? Dus een XSLT waar je alleen je eigen veldnamen moet invullen? Ik ben zelf ook bezig geweest met bankafschriften maar dan via een $variabele waarin de XML wordt ingelezen. Vervolgens met een script en custom functie de verschillende transacties parsen. Voor grote bestanden is het alleen niet snel.
  11. Ik maak veel gebruik van Save Records as PDF en sinds enige tijd ook op de server, via een PSoS. De PDF wordt dan aangemaakt in de documentsfolder op de server en vervolgens met behulp van de BaseElements plugin geïmporteerd in een remote containerveld. Gaat prima, behalve dat de preview ontbreekt: de PDF toont als icon. Daarvoor heeft de BaseElements plugin een functie ConvertContainer. Maar ik heb toch het idee dat het niet altijd naar behoren werkt. Niet iedereen ziet de PDF en en soms toont ie toch alleen een icon. Als ik het veld instel op 'image' (dus niet interactief) verschijnt de preview (= de image) bij sommige gebruikers wel, maar bij andere weer niet. Heeft iemand hier ervaring mee of kan iemand mij vertellen wanneer FileMaker wel een nette preview toont en wanneer niet? Server is Windows 2016 en FMS16.0.4, BE plugin v4.
  12. Dit is natuurlijk een software forum maar... de MacMini is altijd een populaire machine voor 'lichte' FileMaker Server toepassingen geweest. Het lijkt erop dat Apple de MacMini echt nieuw leven in geblazen heeft: maximaal een 6Core i7, 64 GByte RAM (prijzig), 4 Thunderbolt 3 poorten en een 10GB UTP aansluiting. Ik denk dat dit voor FileMaker Server wel een populaire optie gaat worden, ofschoon een beetje aan de prijs misschien.
  13. Alweer een jaar geleden, toch even informeren. Op de website van FMI staat een hele lange discussie over dit probleem en helaas worden er allerlei zaken bij gehaald die er niks mee te maken hebben. Het probleem bestaat nog steeds en het komt op het volgende neer: Een interactief containerveld met een PDF blijft leeg onder bepaalde omstandigheden. Na wat systematisch onderzoek lijkt het probleem te maken te hebben met SSL. Ik vat mijn ervaringen op de volgende mmanier samen: 1. Client: Mac, FMP15, 16 of 17. Server: Windows 2012R2, FMS16.0.4, SSL actief: alles werkt mits ik met de volledige geldige domeinnaam van het certificaat aanlog. 2. idem: als ik aanlog door als host het IPadres + naam vh bestand op te geven blijven interactieve containervelden leeg.De content is er wel, want ik kan ze wel exporteren (met een script). 3. Client: Windows10, FMP16 of 17. Server: Windows2012R2, FMS16.0.4, SSL actief: alles werkt, ook als ik als host het IPadres opgeef. De Windows client maakt gebruik van Acrobat DC, de Mac van Preview, maar dat maakt volgens mij niks uit. 4. Client: Mac, FMP15, 16 of 17, Server: MacOS 10.12.6, SSL uitgeschakeld: alles werkt. 5. idem, FMI certificaat ingeschakeld (self-signed): interfactieve velden blijven leeg. 6. Client: Windows10, server als bij 5 en 6: alles werkt, ongeacht de SSL instelling (je krijgt natuurlijk wel een toeter aan waarschuwingen). Het is dus volgens mij een issue met SSL. NB het probleem trad ook op toen het intermediate certificaat niet was geïnstalleerd. De vraag is: treedt dit bij FileMaker Server 17 ook op?
  14. Het blijkt inderdaad gewoon te kunnen: alsnog het intermediate certificaat installeren. Gewoon nogmaals dezelfde bestanden importeren, met dezelfde serverKey.pem en het wachtwoord. kennelijk wordt het bestaande certificaat gewoon vervangen en het ontbrekende intermediate certificate wordt toegevoegd.
  15. Welke plugins zijn dat? Ik meen dat de meeste 'mainstream' plugin's wel updates hebben uitegbracht die compatible zijn met FM17. Heel gemakkelijk niet, maar ik heb bijvoorbeeld mbv van Clipboard functie van de MBS plugin een tabel gemaakt met daarin alle scriptstappen en velddefinities. Daarin kun je dan een full-text search doen en op die manier alle scripts / scriptstappen en velden/tabellen eruit vissen waarin een bepaalde plugin wordt aangeroepen. Een andere optie is om alle scripts en velddefinities te printen naar PDF (MacOS). Dat levert een PDF op die je met behulp van Preview of Acrobat kunt doorzoeken. Is misschien wel de gemakkelijkste optie. Nee, volgens mij niet. Misschien kun je FMServer wel apart downloaden en als test installeren. Niet helemaal: je kunt een configuratie voor 5 users aanschaffen. Daarvoor krijg je een licentie voor max 3 FileMaker Servers (1 voor test, 1 voor live en 1 voor ontwikkeling bijv), 5 clients (fileMaker Pro Advanced, Webdirect en/of FileMaker Go connections). Later kun je die configuratie uitbreiden met meer sessies, d.w.z. je kunt aanvankelijk tegelijk met 5 gebruikers aangelogd zijn aan de server. Dat aantal kun je later dus uitbreiden naar max 100 of 250 of zoiets.
×
×
  • Create New...