9 Replies Latest reply on Sep 28, 2012 10:55 PM by hrc

    ExecuteSQL

    jbante

      Why is the ExecuteSQL() function limited to SELECT statements? For that matter, why can't the ExecuteSQL [] script step be directed at FileMaker without an ODBC connection? Plug-ins (some of them free!) have been accessing the full depth of FileMaker's SQL functionality for years. That the native feature should be released with less functionality has been confusing at best to developers with experience in other database technologies.

        • 1. Re: ExecuteSQL
          Vincent_L

          Amen to that !

          We need strong SQL support, with all write and structure function support, most notably UPDATE that's aware of record locking and TRUNCATE that deletes all table content instantly !

          • 2. Re: ExecuteSQL
            Vincent_L

            If the non write function decision is meant to avoid newbie mistakes I'd say make it only available in FM Advanced. We're grown ups !

            • 3. Re: ExecuteSQL
              jrenfrew

              Allegedly...

              • 4. Re: ExecuteSQL
                jbante

                How do you propose that FileMaker accomplish that with calculation functions and script steps, both of which otherwise have complete feature parity between Pro and Advanced versions of FileMaker?

                • 5. Re: ExecuteSQL
                  jbante

                  For what it's worth, my question is not a feature request, but a request for some insight into FileMaker's vision of the features and how they fit in the platform. I'm disappointed that others aren't asking more questions with a similar purpose. How is FileMaker supposed to have a "Q&A" with only feature requests to respond to? What appropriate answers can they give to feature requests other than either, "Interesting, we'll think about it and it may or may not wind up in a future version," or, "You can already do that in FileMaker"? That's a very boring conversation.

                  • 6. Re: ExecuteSQL
                    jrenfrew

                    @jbante

                    Isn't the issue that FM keeps product direction even more closely guarded than anything else? And by now we are all good citizens who realise that this line of questioning is fruitless.

                     

                    By looking at the range of questions asked shows pretty much where the push is for developers - improved script writing tools, speed, server functionality to remove heavy lifting and enable plugins for Go, extend the scope of EvaluateSQL, extending iOS functionality...

                    While presumably NOT rocket science it is a useful thermometer and we would hope none of this is really a surprise to the PM's either.

                    • 7. Re: ExecuteSQL
                      jormond

                      While I don't think FMI is ever going to be transparent in their development of FileMaker, this appears to be the start of building a better relationship with the Product Management team.  Getting insight from them about the reasons for decisions ( which they are open about most of the time ), and also providing them with 'real world challenges and successes' ( if I got that right from the invitation ).

                       

                      Feature ideas I think will naturally come up in the discussion, but they also need to be accompanied by the challenge it presents...and the things in FM that helped you solve a problem.  That will let the PM team know what areas to focus on.  90% of the suggested topics so far are feature requests...  While some of them present a good topic to discuss with the PMs, many are just "I want this feature".  And I think that is what Jeremy is disappointed in.

                       

                      After the FM Roadshow came to Rochester ( thanks Rosemary, Mia, and Stephen ), and I listened to some of the discussion afterward, I had a different opinion of some of the changes made.  They make sense, well most of them, and adapting on my part will make me a better developer.  It's also good to know that some of the "features other products have had for 20 years" are on the radar, but there are serious technical challenges that if done wrong will threaten the integrity of FM itself.

                       

                      I hope that some of the feature requests are discussed, not all of them of course, just so we can hear what ideas the PM's have.  Because they may have a better approach that will have more far reaching benefits for us.

                      • 8. Re: ExecuteSQL
                        jbante

                        Having a forum to hear FileMaker's responses to feature requests has its uses, but I think the pro-level developer feature requests easily devolve into an echo chamber that fails to represent the desires of the market of people who pay for FileMaker licenses (except maybe the Advanced version). I'd like a penny for every time I've heard or read a developer saying, "Programming language X has feature Y that I like, so FileMaker should just let us use X natively within FileMaker." These kinds of features have the potential to degrade the cohesion of the platform. One of the most important aspects of FileMaker is the internal lack of dependence on prior education in what someone else on another thread described as "peripheral elements." You don't have to know any other programming technology to make useful applications in FileMaker (unless you have to integrate with them, and possibly not even then). The more users have to know about non-FileMaker technologies to make high quality applications in FileMaker, the more the value proposition of FileMaker gets diluted.

                         

                        Clearly developers have active imaginations for features that would make FileMaker a better product, and its great that FileMaker is taking the time to listen. But FileMaker, like any programming tool, has its own baked-in biases about what may be better and worse ways to accomplish things. I think developers would be well served by trying to learn what those biases are, so we can write better apps by working with the grain instead of against it; and FileMaker would be well served by articulating those biases so developers are better equipped to make apps that make FileMaker look good.

                        • 9. Re: ExecuteSQL
                          hrc

                          And again: Amen to your post!

                           

                          Let me add:

                          I have worked with SQL and SQL Plugins for quite some time.

                          Some other developers and myself have found limitations to the FileMaker SQL engine: We were unable to use nested statements (virtual tables). You can show that they don't work using really simple textbook examples.

                           

                          If ExecuteSQL shall be the power tool we all hope for, the SQL standards should be implemented more comprehensively.