Jump to content

hans erik

Leden
  • Content Count

    827
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. OK, maar als je via een PSoS een aantal scripts laat lopen die een tijdje duren (los van de vraag of dat zinvol is), dan neem ik aan dat de respons ook afhankelijk is van de 'wait on completion'. D.w.z. de DataAPI geeft pas iets terug aan de client als het serverside script klaar is? En hoe zit het met de scope van globale $$variabelen en global fields? Is elk script technisch gesproken een sessie?
  2. ik denk dat de eerste oplossing het meest voor de hand ligt: extra relatie maken tussen factuur en factuurregels op factuurID, gesorteerd op aflopende stuksprijs. Als je dan een record toont in je factuur (hoeft NIET in een portal te zijn, omdat de relatie is gesorteerd), dan krijg je automatisch de record met de hoogste stuksprijs. Als er twee or meer records zijn met dezelfde (hoogste) stuksprijs, moet je ook sorteren op een andere key die bepaalt welk van de mogelijkheden de voorkeur heeft en dus in de factuurlayout verschijnt.
  3. Ja, in die zin dat de Data API voor Filemaker de mogelijkheid biedt om geld te vangen voor de communicatie. Bij de PHP en XML publishing is dat niet zo: er zit monitoring mechanisme op en er is dus geen bovengrens aan de hoeveelheid data die je heen en weer kunt sluizen. En dat is vanuit FMI bekeken niet aantrekkelijk.
  4. De lijstweergave is daar niet de aangewezen ‘view’ voor: wat jij wil kan natuurlijk prima, als je gebruik maakt van een portal, die gebaseerd is op de relatie die je beschreef. Dus: je hebt een layout van je reparaties, in Form view (formulierweergave, 1 record per scherm). Daarop maak een portal gekoppeld aan je ‘gerelateerde’ tabel (dat is een zgn ‘self-relationship, die koppelt met alle records die voldoen aan het criterium). Die portal toont dan de juiste records.
  5. Altijd mooi als er zelf achter komt. Geeft een extra fijn gevoel.
  6. Dat is wel een gave extra, Menno. Je gebruikt de SQL update functie, en die wordt niet ondersteund in de executeSQL van Filemaker zelf... Raar eigenlijk dat de tooltip dus WEL een 'hover' functie triggert, maar dat er nog steeds geen 'onHover' script trigger voor layout objecten is!! Het zit dus wel in Filemaker, maar ze zien daar kennelijk niet het nut om het ook op een normale manier te implementeren. Ik kan me herinneren dat ik ooit in Filemaker 12 (IWP) een tooltip moest gebruiken om een probleem met een URL te omzeilen. Dit zou echt een enorme verbetering zijn.
  7. Ik probeer een XML bestand in een tabel te importeren via een server-side script, met PSoS maar uiteindelijk moet het een scheduled script worden: - XML en XSLT bestanden staan in de Documents-folder op de server; - gebruiker heeft [Full Access]; - import records staat goed ingesteld (juiste padnamen in een $variabele, gebruikmakend van de Calculation optie bij XML en XSLT). Ook combinaties met file:, filewin: gecheckt. - FileMaker Server 17.0.4, geen Encryption at Rest oid, alle extended privileges OK. Op MacOS 10.13 als server werkt het uitstekend, op Windows Server 2016 krijg ik een FileMaker Error 9 (insufficient privileges). Ik mag records aanmaken, wijzigen en deleten, maar het script werkt niet! Iemand een idee? Bug in de XML import?
  8. Ik heb nu de aanmaak van de PDF maar weer naar de lokale WS gehaald en tot nu toe heeft de fout zich niet meer voorgedaan... Ik denk dat het te maken heeft met het schrijven naar een bestaande PDF (append) eventueel in combinatie met een read-protect password.
  9. In theorie zou je iets dergelijks wel kunnen realiseren met FMS: je application server is dan een database die je benadert vanuit de user. Op die server staan in principe geen gevoelige gegevens. Als je iets nodig hebt uit de 'echte databse' in het private network (een tweede FMS) dan laat je de application server via een server-side script de data ophalen. Maar dat heeft natuurlijk wel nadelen: -complex -niet supersnel, want er zit de nodige overhead bij. de data worden bovendien onvermijdelijk buiten de firewall opgeslagen, ook al is het maar tijdelijk. Ik zou eerder kiezen voor een goed doordachte security setup van je Filemaker bestand, sterke passwords en misschien een goede VPN. En ik zou zeggen: laat het testen.
  10. Als je de 'data niet direct mag blootstellen aan de buitenwereld', hoe doen ze dat dan met andere systemen (MySQL, MSSQL)? Dat zou ik dan wel eens willen weten. En volgens mij is de security van FileMaker best in orde.
  11. Daar is iets voor te zeggen. Maar aan de andere kant: ze geven met Filemaker Pro Advanced wel weer iedereen toegang tot allerlei high-end ontwikkeltools. Ik zou zeggen: geef er dan een optie bij om extra features in de console aan en uit te zetten. De CLI straalt geen moderniteit uit, zeg maar.
  12. Alleen (juridische) tekst, met als enige graphic een PDF of JPG als achtergrond. Lettertype alleen Calibri of alleen Arial (dat laatste omdat sommige gebruikers problemen met Calibri ondervonden!). Alle tekst wordt via een theme geformatteerd. Geen vrije invoer, d.w.z. tekst die in velden geplakt wordt via een autoCalc van formatting gestripped. Maar dat is geen garantie voor bagger, helaas. Ik maak wel heel veel gebruik van de 'sliding fields' optie: alles schuift naar boven toe op. Je hebt kleine alinea's en langere lappen tekst, en indents, tabs etc. Altijd in één script, maar wel meestal in twee stappen: een rapport en een bijlage, afhankelijk van de inhoud en opties. De PDF's worden eigenlijk nooit groter dan 350KByte, ook al omdat ik ervoor zorg dat achtergrond graphics beperkt blijven. Optioneel kan de inhoud tegen kopiëren beveiligd worden met een wachtwoord, dat de gebruiker overigens niet weet en ook niet zelf kan wijzigen. Ik ook!! Ik denk toch aan een probleem in de PDF engine die FMI voor Windows heeft gebakken. Ik heb al eerder problemen gehad met gebruikers die Calibri gebruiken en vanaf een soort Citrix omgeving werken. Het probleem komt erop neer, dat regels grotendeels 'samenklonteren' in de eerste positie. Dus alle letters worden op de eerste positie geplaatst, een soort zwarte brij. En ik kan het in zoverre reproduceren, dat als ik de tekst uit een paar probleem alinea's naar de Mac client kopieer, het daar ook tot rommel leidt. Het zit dus bij dat probleem in de metrics van de karakters, die op dat citrix platform via het clipboard binnenkomen, het lijkt erop dat de PDF generator de karakterbreedte soms op nul zet, heel vreemd. Heb gedacht dat het aan de versie van Calibri ligt bij de client, maar als ik de PDF on server laat generen zou dat geen rol moeten spelen, maar het probleem bleek alleen met Arial op te lossen!
  13. Ik heb de cache nu alweer een paar dagen op 7000 MByte staan, maar het probleem met FMSE blijft zich voordoen. Altijd op dezelfde plek: ik maak een PDF aan. Het laatste 'teken van leven' is vlak vóór 'Save records as PDF'. Er is dan eerst wel een plugin functie uitgevoerd, maar daarna volgen nog verschillende 'normale' scriptstappen voordat de logentry weggeschreven wordt. En het wegschrijven van de logentry is natuurlijk ook een 'gewone' scriptstap, met een commit. Ik denk dat de plugin dus niet de boosdoener is, maar toch iets in die Save records as PDF.
  14. Aha! Dat zou de reden wel eens kunnen zijn. Ik had de cachesize in FMS16 op 8000 MByte staan, maar ik had begrepen dat FMS17 die zelf optimaliseerde, ook al omdat die instelling uit de console verdwenen was. Dat blijkt dus helemaal niet zo te zijn. Heb hem nu op 7000 staan (was 512MB!!). En FMS17 heeft de instelling van FMS16 natuurlijk niet overgenomen, want je doet een uninstall bij de upgrade.... Het aantal scriptsessies zal niet gauw de bottleneck zijn, er draaien eigenlijk nooit meer dan 4 scripts tegelijk en nooit asynchroon. Ik kijk het zo even aan. Nu we het er toch over hebben: het aantal hostedfiles maakt toch niks uit? Ik bedoel: FMS reserveert geen extra geheugen als dat aantal op de default van 125 blijft staan. Wat ik niet terug zie is het aantal dataAPI connecties. Of wordt dat gewoon bij de WebDIrect en FMP connecties geteld? Dank! HE
×
×
  • Create New...