sal88
-
Content Count
316 -
Joined
-
Last visited
-
Days Won
2
-
Thank you Wim!
-
Hi all This the last thing I need to implement on our Server as per FileMaker's installation and configuration guide: Make the virtual memory swap file a static size so Windows doesn’t attempt to adjust it. Use the recommended file size amount Am I right in thinking that this is in the attached section? If so, on which drives should I be specifying the swap file size? And what would the initial and maximum size be? Thank you
-
Window restoring to size of other layout
sal88 replied to sal88's topic in Cards & Window Management
Resolved by opening a backup, removing any on open or on close scripts, removing any custom menus and then restoring the window and resizing to a more appropriate size. -
It turned out there was a server-side scheduled script that included export/import steps, that had not finished, or had frozen. There were multiple instances of it running. A reboot of the server resolved it
-
Hi all I've created a PDF export script. However when I run it on the server (admin privileges are ticked) I get error 800 on the save as PDF step. I can see the file appear in the destination, but it disappears after a second. The export path is a variable which is set as "filewin:" & Get ( DocumentsPath) & "Report.pdf" I do not get this problem with the Export Records script step. Any ideas? Thanks
-
Hi all Just wondering if anyone's ever experienced this odd problem. When I restore the window of our main Clients layout (which upon startup is maximised), its size is that of another layout (Case list), which loads on startup, and is only ever shown in its own floating document window. I then load up an offline backup, and then restore, resize to a reasonable size, go in to layout mode, perform a small change and then save. This fixes the issue for that session. However when I load up this 'fixed' backup file locally again, instead of starting maximised, it now loads up in the restored size of the Case list, regardless of which layout. But also the menubar is not visible, which is one of the properties of the Case list. The next time I load up the file it loads up maximised but restores to the 'wrong' size, and the menubar is still missing. Has anyone experienced anything similar? Thanks
-
Hi all My webviewer displays a list of messages from a related table. The structure is basically as follows: Webviewer source: "<html><body>" & list (messages::html_web) "</body></html>" html_web field [stored calculation]: From & " sent message at " & Creation_Timestamp & ":<br>" & Body Is there a simpler way of doing this? It seems to be it would be better to have the webviewer do all the calculations, and get rid of the html_web field. This would speed up any development changes and free up some space. Would JSON be the way to go? Thanks!
-
Hi all Our server decided to shutdown just now due to windows updates. Here is the FMS log: 2019-12-11 17:18:45.641 +0000 Information 745 FM Stopping FileMaker Server processes... 2019-12-11 17:18:45.675 +0000 Information 704 FM Stopping Database Server process... 2019-12-11 17:18:45.704 +0000 Information 488 FM Stopping Database Server... 2019-12-11 17:18:45.734 +0000 Information 410 FM Stopping FileMaker Database Engine... 2019-12-11 17:18:45.770 +0000 Information 140 FM Closing database "BS"... 2019-12-11 17:18:45.778 +0000 Information 140 FM Closing database "Case_Feedback"... 2019-12-11 17:18:45.778 +0000 Information 140 FM Closing database "ML"... 2019-12-11 17:18:45.778 +0000 Information 140 FM Closing database "ML_Correspondence"... 2019-12-11 17:18:45.874 +0000 Information 168 FM Database "BS" closed. 2019-12-11 17:18:45.994 +0000 Information 168 FM Database "Case_Feedback" closed. 2019-12-11 17:20:34.367 +0000 Information 743 FM Starting FileMaker Server processes... As you can see it did not close the last two databases in time. As such, I've just had to wait 30 minutes for one of those two to finish 'checking'. It has now succesfully opened however and we can access it. Obviously we need to disable such automatic Windows shutdowns. But is there another safety net I can put in place to ensure that no shutdown procedure can complete until all FMS services have stopped? And that FMS services cannot stop until all databases have successfully closed? Thanks!
-
It has crashed a few times (far less frequently however). I have gone for the global multikey field option, party populated by ExecuteSQL. Filter criteria is now only user defined.
-
Thank you for all the responses guys! Having had a little play with JSON (and I had no idea about variable repetitions!), I feel ready to tackle this. I'm going to go for the hidden repetition option. The layout will have 5-10 repetitions of the same field(s), with only the one that matches that window/record being visible, this will be determined by either JSON or native FM variables. By coincidence, Microsoft Teams has only just released the multi window capability. I'm not sure if the delay was for similar technicalities as my scenario though :D. But it would appear there is (for good or bad) a demand for this kind of multi tasking. https://www.linkedin.com/feed/update/urn:li:activity:6597210269712207873/ Comment, love your idea of a repetition per record rather than window. This means they can close the window if necessary, and then come back to their draft message. Thank you. In fact, I may begin with just allowing users to close the Case window, and it storing the message in a JSON variable. If I can't solve the styling issue with a reverse 'GetAsCSS' CF such as this one https://www.briandunning.com/cf/855 I will disable window closure if there is styling present. Once that is working I will move on to multi window. Thanks again!
-
Great memory LaRetta! It is a different portal, but what a coincidence that the issue occurred after an upgrade. I've tried a brand new portal and tables etc but no luck. For now I have replaced: PatternCount ( ¶ & Clients::multikey_Cloud_Machines & ¶ ; ¶ & Machines::ID & ¶ ) with: not IsEmpty ( FilterValues ( Home_Clients::multikey_Cloud_Machines ; Home_Machines::ID )) This has fixed it, though you can still see a delay when the popover is being closed. If it comes up again I will implement a multikey field relationship, the multikey field being updated on record entry. Thank you both for your help!
-
Did you click away from the popover as soon as you had populated the field? And are you on 18.03? I just tried it on version 17 and the issue didn't occur. Thanks
-
Hi Comment Please find attached. I think this is down to some poorly made filtering formulas in the portal: 1. The problem doesn't occur if I delete around 7000 of the portal records 2. It also doesn't occur if I remove the carriage returns from: PatternCount ( ¶ & Clients::multikey_Cloud_Machines & ¶ ; ¶ & Machines::ID & ¶ )) in the portal filter 3. However if I remove all the other filters and leave just the above one (with carriage returns) it is also OK Thanks! portal_popover_filter_problem.fmp12
-
Hello all On FM 18.03, the closing of a popover, the button of which is in each row of a portal, causes FileMaker to close. This appears to only happen when the fields which are in that popover (the portal records) are edited. Has anyone else experienced this? Thanks
-
Sorry I should have quoted. I was referring to OlgerDiekstra's post...which they've now edited. Is multi-user record locking ever an issue?