typewriter

If you need the control over record display like you showed in your example, you could consider using a webviewer in combination with a html table and some css.

If your code worked allright prior to FM16, it may have to do with changes in the Webviewer. I have a similar problem with FMP16: a GoogleMaps display with an SVG custom marker as overlay. Marker and other objects print to PDF, but the map doesn't. In FM15, it works fine. (problem is the same on Windows and Mac).

Well, I repeated my comparison tests many times, with simple queries and queries that require a lot of processing and although I get consistently longer process times, results are not always as bad. Sometimes the difference between a normal run and a 'record in use' run is only 30%, which I do not consider dramatic. Which leaves me wondering how and when Filemaker executes a FQL query on the server. When a record is locked, will it still use the index? And what information is cached?

Did some testing on a table with 100K records, running on a 4core MacMini w/FMS16: depending on the client and network, the speed difference is at least 10fold. I also did some testing in a local file (no network, single user) and in a peer-to-peer setup. When running locally the 'record in use' effect is still there, but only a factor 2. My guess is that Filemaker can't use the index when a record is in use, resulting in a slowdown. In a peer-to-peer setup, the diffrence is much greater, up to 700x!

Well, the point here is this: for Table Occurrences I always make a separate set of 'reference TO's' which are only used for SQL, and 'behind the scenes' tasks like track and trace functions. Once you have these TO's it doesn't make sense to rename them, and you can blindly type their names in SQL code, knowing that they'll be there and represent what they're supposed to represent. For field names it's different, but frankly I don't see the point in changing names later on, especially once you've started scripting. I know that Filemaker is so nice to allow this, but using SQL in a professional manner I would suggest treating the rest of the database in a professional way too. Noblesse oblige... Lately I have had to take over solutions that other developers made and I came to hate wading through layers of custom functions, it is a real pain and at the end of the day it will cost a ton of money too. I wish FMI paid more attention to best practices... By the way: are you suggesting that FQL may be responsible for holdups when loading records this way?

If they only would add SVG support for the 'background graphic' for buttons and other layout objects, that would solve everything. To me it seems that the button palette was developed by a different department than the one that worked on the tool palette! Perhaps they should meet at some time...

indeed these blog entries and manuals are well worth reading. I might add my two cents in that you should consider keeping your FileMaker solution 'SQL clean'. By that I mean three things: 1. use names for tables and fields so that you don't need escape codes. It makes your SQL much nicer to read and maintain. 2. use a separate set of Table Occurrences for your SQL. SQL operates without the Filemaker context, so there there's no need to stick to your schema and you don't need cryptic names in your SQL statements. 3. don't use SQL in field definitions. You will run into record locking conflicts without knowing it. HE

Still not decided whether I should use these SVG buttons at all, although I am a strong supporter of SVG in other areas (such as the webviewer). Has anyone found a way to REPLACE an SVG graphic with another one, so that all the buttons with that icon in my solution will change automatically? AFAIK, the SVG is copied to each and every object that uses it and has no 'link' to the repository, does it? So, suppose I have developed a big solution with a particular button appearing at 300+ places and my customer prefers a different graphic, guess what? I'll have to change these 300+ buttons one by one. Well done, FMI. HE

Oh well, that's my fault. I hadn't taken the time to update the profile. Thanks for the feedback. I would be pleased to see additional authoring functions in FMPA17. Like the ability to open a particular script like I mentioned in my post. But displaying the ID's of layouts, scripts and fields in listings would also make life a little easier for people who need to take care of other developer's creations. This consumes some screen real estate, but that that is no probem anymore. By the way, the Open Script Workspace... command in combination with copy/paste works pretty well. And for processing the FIleMaker XML, I'd recommend any developer to take a good look at the MBS plugin ...

Is it possible to use AppleScript to open the Script Workplace, select a particular script and even scroll to a particular line? I looked through several AppleScript sources (there are not so many...) as well as the Dictionary of FIleMaker Pro Advanced 15, but all examples seem to deal with using the database (i.e. finding and manipulating records), not authoring. Why would be handy? I have an authoring database where I can store the scripts and scriptsteps of a solution. These are converted from FIlemaker XML using the MBS plugin, not that complicated. Then it's possible to select the scriptsteps that need attention. But locating these scripts in the original solution is quite time consuming, so an AppleScript would save me tons of time.

The exact dialog is a simple progress dialog: Sorting...' with a progress bar and a Cancel button. No information on the table or field, not even the number of records or bytes. Users often click the cancel button and the dialog disappears, but often re-appears a couple of seconds later. Although a MacMini is not the fastest beast on the block, there are only 3 or 4 users at maximum at the same time. Problems seem to be worse when connected through a VPN. The server could be upgraded form an earlier version, I'll check on that. But you have to remove a previous version of FMS first when upgrading to FMS16? I did not do the upgrade myself. All layouts are still in Classic. I have told the owner that that would be an issue to be addressed. May the use of SuperContainer have influence?

Where can I find information on Filemaker Server 16 caching and (re)calculation? I have this problem: a customer that I took over upgraded to Server 16. Workstations are still on 15. Now, a soritng... status dialog appears very often, something that didn't happen with the previous version (which was 15, I believe). I know there are changes made to the way FMS determines what to recalculate and when, but I can't find a document or webpage with a good explanation. I'd like to get a clue about where to look for the source of the problem. Anyone with a reference or hint where to look? Some data: server is a MacMini corei5, running 10.11.6, 12 GByte RAM, with a normal HDD (no SSD yet). Server cache is set at 4Gbyte. Database is not particularly big, but has a lot of filtered portals (where you'd have many related records that are filtered on the client). This may be a cause, but then: why now and not in a previous version of FMS?

Hi I am experimenting with Treemaps using the D3.js and D3plus.js libraries in FMPro Advanced 15 and the Webviewer (OSX 10.11). D3plus.js is really nice as it makes it much much easier to implement a Treemap using a simple JSON object containing your data. But sometimes thing don't work as expected and I don't fully understand why: - I invoke D3plus code in a FileMaker global text field, as a data:url, iincluding the D3 and D3plus libs in an external reference (I don't include the complete code in the text field). So these are loaded at runtime. - this works fine, but sometimes the treemap hich is a complex SVG graphics generated by D3) defaults to a 200x200 px area. Reloading the webviewer usually fixes the problem (or manually changing the HTML body, by adding a space, wihich forces the webviewer to refresh its contents). But my question remains: why and when does this happen? My guess is that at times the Javascript code is not loaded in the proper order, but I can't figure out how to influence this. The D3.js is invoked prior to D3plus.js, and all D3plus code is executed after these libraries are invoked. Anyone with similar issues?

You might check out ISO productions. Matt Petrowsky made an instruction on how to make a donut chart using D3.js, a very detailed step-by-step guide. Another valuable source is the FileMaker WebViewer Integrations library by Jeremy Brown form Soliant Consulting.

Yes, you are right in what is (not) in the EULA. But I had a long discussion about this with a FMI sales rep here and he assured me that all users must work for the same company. Perhaps he was not briefed properly by FMI? Or FMI really has not thought this over themselves?