Record Locking In FileMaker 6 and earlier versions, record locking occurred when a guest on the network clicked into a field. That's was all that was required to prevent others from changing the record. Unfortunately, this also prevented other guests from copying data from a locked record and other basic features. FileMaker 7 has changed how record locking works. In order for a guest on the network to lock a record, he must actually modify a field, allowing user to work with a record without locking it. However, the most important change is when scripting for record locking. You don't want to test if the record is locked by setting a field to a value. FileMaker 7 introduces the Open Record/Request script step which attempts to lock a record without modifying it. If the record is locked, an error of 301 will be returned. If the record is not locked, this script will lock it until the Guest exits the record manually or the Commit Record/Request script step is intiated.
Hall of Fame I started working with FileMaker 25 years ago and a lot has changed. Here are the folks I think need to be recognized for their effort in shaping the early FileMaker (in no particular order):
Level: Intermediate Category: General Tuesday, April 25, 2017
One of the most common FileMaker fallacies is a web browser client will save money. I hear it almost weekly from the people who contact me directly. I get it. Everyone wants to save money. But, just because a web browser is free doesn't mean it saves you money.
Yes, FileMaker clients require the purchase of licenses for the server or a copy of FileMaker Pro, which comes with a license. Even FileMaker Go requires a license, even though it can be downloaded for free. That's money straight out of your pocket! However, this viewpoint is very shortsighted since developing in PHP or XML (Custom Web Publishing or CWP for short) can be costly, inefficient and limiting. Even if you decide to use WebDirect, you have to pay for licenses, limit what you can do and end up taxing the FileMaker Server machine.
The other frequently mentioned objection is that a web browser is universally available. That hits the nail right on the head! If your audience is unknown then a web browser is the best choice since there is no way to distribute a client to them. But, if you are deploying a solution to the employees in your company then a FileMaker client can be distributed easily. A FileMaker client can also just as easily access a solution locally or remotely, and the experience, especially, is far better.
If that's not enough to convince you to use a FileMaker client, let's consider specific points about why a FileMaker client provides a better experience for the user than a web browser.
Output Web browsers aren't very good at printing. Web browsers are designed for surfing the web. Yes, there is a print option under the File menu of every web browser but it's not their forte. The strength of a web browser is to provide information electronically from web sites on the internet. Specifically, web browsers don't slide objects, hide objects or even preview information like a FileMaker client. This severely limits the effectiveness of reporting, the hallmark of database solutions, whether printing to a piece of paper or generating a PDF document.
Submit Web browsers typically refresh content when a user clicks a button to submit information he has entered. For example, a button that submits a new record to FileMaker via PHP or XML, only sends the data back to the server when and if that button is clicked. If someone closes the window of the web browser, the data is lost. A FileMaker client commits the data implicitly so it is harder to lose, even when closing a window without committing. To be fair, WebDirect does provide implicit data interaction such as conditional formatting updates and seeing data when updated from other users. However, it will never automatically save data from a closing window unless a submit button is clicked first. This WebDirect ability also taxes FileMaker Server while a FileMaker client can do much of the processing on it's own.
Record Locking I find a custom web published solution great for finding, adding and deleting records in FileMaker. When it comes to editing records, a third party application can't support record locking like a FileMaker client. Record locking occurs on a FileMaker client when someone starts editing a record. That record becomes locked to all other edits until the user commits the record. What ends up happening in a web browser is two people can edit the same record at the same time. Whomever submits the changes last overwrites the other users data. While custom web sites don't have record locking, WebDirect does support this feature since everything is done on the FileMaker Server. Again, this takes a lot of work and is one of the reasons the numbers of users in WebDirect are limited by hardware.
Script Steps I love scripting! If I publish on the web, I am severely limited in the steps from which to choose. For example, I can't show a custom dialog on a custom web published database, something I employ quite often. This requires me to recreate this simple feature with additional code. I can use the Show Custom Dialog step in WebDirect but many other script steps are not supported, fully supported or act differently. I prefer to have the full scripting repertoire of a FileMaker client at my disposal!
Here's a comparison of the available Miscellaneous script steps available for FileMaker Pro (left side) versus Custom Web Publishing (right side). The steps not available on the FileMaker Pro side are iOS or Windows specific. This is just a small taste of the limited functionality but it makes my point well. Your scripting efforts will be crippled in a web browser.
Performance depends on many factors other than total users, such as database design (complicated layouts that need to be rendered) and LAN or WAN performance. While a FileMaker client can also suffer from these same slow downs, it helps the server by performing jobs like calculating, scripting and anything else that doesn't require interacting with FileMaker Server. This allows FileMaker Server to concentrate on serving data to FileMaker clients, enabling more users with lower hardware requirements.
Multiple Windows Spawning new windows is a powerful ability in a FileMaker client. From menus to drilling down through related data to comparing data in two different windows, additional windows expand the amount of information you can digest in FileMaker. Unfortunately, multiple windows don't translate well from FileMaker to the web. In fact, all you can get on the web is a virtual window which remains invisible to the user. To be fair, FileMaker Go supports multiple windows but not the powerful overlapping windows of a true FileMaker client.
Import and Export Custom web sites do not support the Import Records or Export Records script step in way shape or form. WebDirect partially supports import and export but security limits access to arbitrary locations on the OS, often referred to as the sandbox, as well as limits what formats can be used for exchange. Here's a summary of the limitations in WebDirect:
Not supported in mobile browsers
With dialog or Specify data source options are not supported
Comma-Separated Text, Tab-Separated Text, DBF, Merge, and Excel file formats are the only supported formats
Not supported in mobile browsers
.fmp12, XML, or Excel formats are not supported
If the Specify output file option is selected, the specified file path is ignored
Output is to the web browser’s default download location
If field data or record data is too long for the export format, the Get(LastError) function returns 0 rather than 736
One result of these limits is you can't import from one FileMaker file or table to another FileMaker file or table... something I do frequently.
Interface Design A FileMaker client interface is so easy to design with drag and drop. You can place objects exactly where you want them. If the position of a field is off by a little, just nudge it with the arrow keys. While you may have a WYSIWYG web editor, the conversion to a simplistic web language like HTML just approximates your design. It's also still going to require hand coding for the FileMaker PHP or XML, meaning you are still fumbling around with coding. While this limitation does not apply to WebDirect, since it uses rendered FileMaker layouts, the rendered fidelity is often imperfect and can vary from web browser brand to web browser brand. A FileMaker client never has to translate or render any layout design since it is native, allowing for the exact same experience for every user.
Searching Replicating the sophisticated search engine features, available in a FileMaker or WebDirect client, is a lot of work with PHP. It's almost not worth the effort. I'm not talking about a straightforward AND find. While that requires some programming, you can pretty much copy and paste it from one project to the next. What is going to test your coding abilities is defining an interface for new requests, omits, constrains and extends, which are built-into the FileMaker interface and are also pretty easy to replicate with scripting if you hide the Status Toolbar.
Container Fields It's easy enough to display the contents of a container field using PHP but entering content is a whole other story. Searching the internet usually comes up with tons of solutions to FileMaker problems but not this one. They all point to plug-ins but nothing native in FileMaker. WebDirect supports container population with scripting so it's just as easy as a FileMaker client.
Generating PDFs Creating a PDF from FileMaker is limited to FileMaker Pro, Advanced and Go due to licensing restraints. Each time FileMaker, Inc. sells a copy of FileMaker, they pay a licensing fee to Adobe to use their PDF code. Since WebDirect and custom web published solutions are essentially royalty free distribution, there is no way to accurately calculate the fees owed.
Snapshot Link Snapshot Links are great in workgroup environments. Instead of telling a person over the phone to navigate to this layout, perform this find and sort the data, just send them a Snapshot Link. They just click on it and FileMaker shows your colleague the same information you are viewing. This feature is no supported in custom web publishing and only partially supported in WebDirect. And, even though a Snapshot Link can be saved via WebDirect, it still tries to open FileMaker to show the results since the .fmp12 extension is not supported by a web browser. So, I'm not clear why this feature is supported in a WebDirect.
Stacked Objects I love stacking objects on top of each other in FileMaker. For example, you might have two fields on top of each other. The field on the bottom allows entry and has a drop-down list attached but displays a key value once selected. The field on top doesn't allow entry but displays a value from a related table and hides the key value in the field beneath. In a FileMaker client, the field on the bottom comes forward when clicked since the field on top doesn't allow access. WebDirect doesn't support clicking through to a hidden object and custom web publishing won't even let you stack.
Table View I would never publish a solution for a client using a Table View. It just doesn't have enough control over the interface. However, I often use Table View for development layouts. I like being able to quickly add a field to a layout to troubleshoot issues. I can rearrange columns, resize columns and even make a row taller. This level of functionality will never likely be supported in WebDirect because of the complexity and would be nearly impossible to emulate with PHP.
RTF No, not RTFM. RTF is rich text formatting or the formatting you apply to text in browse mode. Text formatting in layout mode shows on all clients except CWP, of course. However, if someone changes text in browse mode in a FileMaker client, a web browser client will not see the rich text. The same is true when applying changes to text in WebDirect. Only plain text will be sent to FileMaker Server. This isn't so bad since I don't believe in browse mode text formatting, as it overrides layout settings. However, I occasionally allow users this feature under isolated conditions when then benefits outweigh the disadvantages.
Custom Menus FileMaker Custom Menus have no effect in WebDirect or CWP. That means all your solutions have to be completely button driven. For years, I have been hiding seldom utilized navigation and reporting functionality under a menu because it just takes up too much space. I could make a special report layout or a main menu navigation layout but that just requires too many clicks. Plus, I can't use a keyboard equivalent like I can in Custom Menus.
Script Triggers While CWP supports no script triggers whatsoever, FileMaker, Inc. states in their WebDirect guide to limit the number of Script Triggers, unstored calculation fields, portals, panel controls and in general, the number of objects in list view, in order to reduce the amount of processing FileMaker Server has to do. On top of that, WebDirect doesn't even support the OnLayoutKeystroke and OnObjectKeystroke script triggers and has severely limited support for OnObjectModify as it relates to capturing keystrokes. In addition, the Window triggers will react to a browser refresh and not react to the closing of a web browser window under certain circumstances, making them unreliable and unlike their counterparts in a real FileMaker client.
Single Sign-On (SSO) I'm sick and tired of entering my credentials for every application and so are a lot of other people. That's why single sign-on was created. Unfortunately, while a FileMaker client fully supports SSO, CWP and WebDirect do not. If you are using ODBC via CWP or WebDirect, it will be necessary to log onto the ODBC source separately from the FileMaker solution when needed. This makes FileMaker seem clunky to state it plainly.
Participate If anyone has any additional CWP or WebDirect limitations, please add a comment below. I'd love to hear about it. I'm also fallible so please let me know if I've made a mistake in my chracterizations of CWP or WebDirect. I'm always open to being humbled in order to learn something new. Thanks ahead of time for your participation!
Conclusion It's in your best interest and your client's interest to steer them towards a FileMaker client whenever possible. If they need a web browser for an unknown audience then by all means, break out your best web tool and start programming the acronyms like PHP, XML, HTML and CSS. Even WebDirect is great for quickly publishing a public web site in lieu of PHP version under development. WebDirect is also the only client available for Android, requiring you to use it when FileMaker Go on an iPhone is not an option. But, whenever possible, use a FileMaker client for the best experience, performance and feature set. It won't cost you any more money upfront!
I have used FMP web solution for 7 years for grant submissions and grant scoring in my state. Every version of FileMaker gets better with web rendering.
I do agree with the limitations you describe. In FMP 14 and earlier the 'spinning wheel' lag was horrible. Version 15 fixed most of that but hosting solutions changed dramatically catching many by surprise.
I love FMP even though it frustrates me sometimes :)
I agree 100%. Each version gets better at rendering layouts and supporting features but always at the cost of server performance. WebDirect is a good solution if you make sure to heed it's limitations. Thanks so much for your feedback!