The order catch is that many developers copy and paste the field table occurrence and the field name directly into their main query, so when you want to rename your field, you will break your SQL. If FileMaker would like to confuse you on purpose, they do it right. I mean you have still to learn some SQL, which has a very different syntax than the regular FileMaker syntax, it has also a very different logic, moreover, as it is not FileMaker native language - you have to type it by yourself, and not make any mistake! Furthermore FileMaker provides you some dynamic parameters, which are inconvenient, because they need to be put in the function parameter in the correct order (like in FileMaker custom functions), but when you call them in your main SQL query you have to call them in the correct order (unlike in FileMaker custom functions) with always the same name: a question mark «?». In this article we are going to explain how to implement portal filtering in FileMaker portal using SQL techniques, because it is easy, powerful and extremely flexible! Editor’s note: Today I’m pleased to present a guest article and accompanying demo file written by Joel Englander on using ExecuteSQL + a global multi-line key as an alternative to FileMaker’s built-in portal filtering mechanism, with dynamic portal sorting included as an added bonus.ĭemo file: fm-sqlportal-filter-and-dynsort.zip (75 Mb compressed, 230 Mb uncompressed)
0 kommentar(er)
