Jump to content

Matt Klein

  • Content Count

  • Joined

  • Last visited

  • Days Won


Matt Klein last won the day on July 30 2013

Matt Klein had the most liked content!

Community Reputation

1 Neutral

About Matt Klein

  • Rank
    Certified Developer

Profile Information

  • Gender
    Not Telling
  1. I just ran into an issue where I imported data that was in all caps into a Filemaker table from an Excel spreadsheet. I then used TextStyleAdd( field1; Titlecase) to change it to title case. In FileMaker, it looks properly transformed. If I copy that transformed text and paste it into another FileMaker text field it still looks transformed. If I copy that transformed text and paste it into a text document OR I export that field to anything other than a FileMaker file, the text is in its untransformed state. Steps to reproduce: 1) Transformed "HELLO" to "Hello". 2) Copied "Hello" and pasted into another FileMaker text field. Result "Hello" 3) Copied "Hello" and pasted into text document. Result "HELLO" 4) Exported the field that contains "Hello" and opened that export file. Result "HELLO" Is this expected behavior? Does anyone know how I can make it so I can copy and paste or export this data and have it hold the transformed state. P.S. I am on a Mac using FileMaker Pro 18 Advanced v18.0.3.317
  2. Thank you for posting your solution! I ended up installing Mojave instead of reformatting the backup drive. Going to Mojave solved the issue....which now makes sense given what you found about Catalina. If I end up deciding to go back to Catalina, I'll now know what I need to do. I'm going to stick with Mojave for now. I was having all kinds of issues with FMS on Catalina....they could have been related to the Full Disk Access settings. They all went away on Mojave.
  3. I just migrated our FileMaker Server from a Mac Mini running MacOS High Sierra and FMS 17 to a Mac Mini running MacOS Catalina and FMS 18. Everything went well except getting FMS to backup to an external Hard Drive. I simply unplugged the External HD from the previous server and plugged it into the new server. It mounts no problem. I gave "fmserver" "Read & Write" access to the drive AND the folders on the drive it needs access to. I can read and write by dragging files onto the drive, but when I try to enter that Default Backup Folder Path under Configuration>Folders in FMS Admin Console I am told that "The path is not valid.". I used the exact same path as was used on the previous FMS. I even went so far as to set the permissions on the drive and folders to allow "everyone" "Read & Write" access. The only thing that I can think of that might be the issue is that the internal hard drive on which FMS is installed is formatted using APFS and the external hd is formatted using Mac OS Extended (Journaled). Before I go either reformatting the internal drive as Mac OS Extended OR the external as APFS, I wanted to see what the community thought. So I'm posting here. Am I on the right track here? Is it because of the difference in formatting of the drives? If so, which format would you recommend.....I'm leaning towards Mac OS Extended? If not, I'm open to any and all thoughts.
  4. Quick question....Is there a way to include a time stamp field in the WHERE clause, but check only the date and not the entire timestamp. In other words, ExecuteSQL("SELECT field1 from table1 WHERE timestamp_Created = ?"; ""; ""; Get(CurrentDate) ) I could do this with greater than or less than conditions in the WHERE clause. I'm just wondering if something like the sample query above can be done instead of the greater than or less than conditions.
  5. Just to keep everyone in the loop, I have confirmed that virtual WebDirect windows do NOT count against the concurrent connection limit.
  6. I believe that is the case. From the FileMaker WebDirect Guide: "When using third-party plug-ins with a FileMaker WebDirect solution, only use plug-ins that have been enabled for the WPE "
  7. Did you ever determine if virtual windows consume a concurrent connection? My guess is no because they are opened in the same browser window, but I don't like guessing on these types of things. Inquiring minds want to know!
  8. Greetings. I just returned from DevCon 2015. Wim, I really enjoyed your session on the Stand By server feature! So, I cornered the man responsible for the creation of and continuing management of WebDirect, Vin Addala, and asked him about the plug-in question I posed here. What he told me was that if you call the Install Plug-in File script step from WebDirect, the plug-ins will be installed in the appropriate location for use with WebDirect. In general, the Install Plug-In File script step acts on the context you are calling it from. So, calling it from Pro installs on the machine running Pro, calling it from Server Side Scripting installs in the appropriate location for the Server Side scripting engine, and calling from WebDirect installs in the appropriate location for WebDirect.
  9. I've done some research and have found that the Install Plug-in File script step will install plug-ins on the server via server side scripting. All the documentation I've seen states that it will install the plug-ins for the Scripting Engine part of server. I see nothing about the Web Engine part which supports plug-ins but the plug-ins are installed in a different location from the plug-ins for the Scripting Engine. Does anyone know if there is a way to install plug-ins for the Web Publishing Engine using Install Plug-In File script step or by some other means?
  10. I'm wondering if anyone knows if the plug-in API returns the script result when calling a script from a plug-in. I know you can pass parameters, but I'm wondering if you call a script with a plug-in and that script has an Exit Script[] step in it that includes a script result, does the API return that script result? I checked several plug-ins that have functions for calling scripts in FM databases and they don't include a function for getting the script result so I imagine the answer is no, but I thought I should ask the question before assuming. I have a long knowledge of using plug-ins, but the API is a mystery to me hence the question. Thanks
  11. Steven - So, is the following statement from the update notes merely a suggestion and not a requirement of the update?: "After applying this software, if you do not have a signed SSL certificate that matches your specific server name or DNS name, request a certificate from a trusted certificate authority (CA) supported by FileMaker, Inc." Thanks for your time
  12. I noticed that one of the updates in FMS13v2 is a fix for the Heartbleed bug(this actually was part of the 13v1a update too.) Am I reading correctly that you must get a custom certificate rather than use the FileMaker default certificate when if you use "Require Secure Connections"? I read this when 13v1a came out and thought I would sit on it for a little while to see what kind of conversations were going to happen. I haven't seen any really. Am I the only one concerned about this? It is my understanding that custom certificates are NOT inexpensive. Approaching clients that have FMS13v1 installed with "Require Secure Connections" turned on, and using the Filemaker default certificate to tell them that they now have to spend more money to get a custom certificate isn't all that appealing to me, mainly because it's not going to be appealing to them. What happens if we install the v2 updater and do not update to a custom certificate? Will FMS still work? Will workstations still see the server and function properly? I can't really test this on a client's computer and quite honestly testing it on our FMS server isn't a good business idea either since we have business critical apps running on it. I might be misinterpreting the documentation for the updater. I have to admit that SSL Certificates and how they work is not one of my strong points at the moment. Anyone? Feel free to move this to another topic. I just didn't see any other FMS13v2 threads and thought this would be a good place for it.
  13. Hmmmm....I did the same thing with my local server that uses the default FileMaker certificate and Get(ConnectionState) properly returned a "2". I am unable to test this at my client site which uses a custom certificate because their web developers added some re-directions to ensure that HTTP cannot be used.
  14. I've been doing quite a bit of research on this and talked to a FileMaker Engineer about it to get clarification. Having the "Require Secure Connections" box marked is NOT required for secure HTTPS WebDirect connections. The only thing you need to do to create the secure connection to WebDirect is use "HTTPS" in the URL. If you have FileMaker's default SSL certificate, you'll get the "annoying" message in the browser. If you have a custom SSL certificate, you won't get the message. This is the case because the "Require Secure Connections" box in the Server configuration effects the traffic passing between FileMaker Server and the clients(Pro, Go, WebDirect) not the traffic passing between the Web Server and the browser. WebDirect doesn't talk directly to the browsers. WebDirect talks to the Web Server which talks to the browser. So, it's the Web Server that handles the secure SSL connections via Browser. The only effect, that I've seen, that the "Require Secure Connections" box has on WebDirect connections is that, when it's marked, HTTP/non-secure connections cannot be made. Without the box marked, a user can use HTTP in the URL and access it without SSL. This I believe can be mitigated by using the Get(ConnectionState) function in the startup script and exiting the app if a non-secure connection is made. It is my understanding that if the "Require Secure Connections" box is not marked, traffic between Server, Pro, Go, and WebDirect is NOT encrypted/secure. So, No, your Pro/Go connections are not secure. All that said, I'm interested to know if you found a solution to your issue of not being able to access the databases with the "Require Secure Connections" box marked. I have run into that same problem and have not found a solution yet.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.