3 Replies Latest reply on Nov 10, 2009 7:29 PM by hiatts

    Working like other RDBMS



      Working like other RDBMS


      As I am new in FM development. Had a training on FM Development. Also have experience SQL Server, Oracle, Access, FoxPro.
      From my understanding, FM is mostly click/drag-m-drop based friendly application development engine. Where Relationship and Table Occurrences are the main base for all type of processing and calculation.

      Bearing the above background, my thoughts are still stick to Stored Procedures, SQLs, batch updates, Triggers.

      I do not have problem with Catalog, Archive type databases because those type of databases uses less functions/calculations/processing of batch records.

      But when I think about building financial type where Monthly,Yearly processing is needed or lets think about this Forum. This forum has lots of totals/numbers, linking to topics etc. features.

      So is there any one who can guide me to the right path to show the secret/best practise of FM development.
      Or you can share some example sites for most common type data processing and solutions.

      Thanks in advance.

        • 1. Re: Working like other RDBMS



          Thank you for your post.


          There are a number of third-party FileMaker Pro books.  You can perform web search using your favorite web search engine.


          This forum is just over a year old, and there are other FileMaker forums.  One that comes immediately to mind is FMForums.com, and that forum has some more advanced topics.


          If you are having trouble with any concept, feel free to post a question here or any other forum, and someone should reply.



          FileMaker, Inc. 

          • 2. Re: Working like other RDBMS

            A few observations that may help you with that initial learning curve:


            Filemaker "grew" out of a flat file "anyone can use it" DB into an RDMS system of one table per file and from there grew into the multi-table per file system they sell today. Sometimes that past legacy shows in how Filemaker does things.


            Filemaker was not originally designed so that users/developers could use SQL expressions to query the database as the standard day in day out process for generating record sets of data to manipulate. (Filemaker has been upgraded so that SQL queries can be performed on DBs using ODBC, but that's not the typical, "just working with Filemaker" approach.) Instead, Filemaker uses a layout dependent approach where example criteria (with logical operators and wild cards) are entered in specific fields while the layout is in a special "Find" mode. This makes simple queries simple, but can make designing complex queries a bit more challenging than simply constructing an SQL statement.


            Filemaker tries to remain accessible to neophyte users with limited knowledge/education about relational database design and/or computer programming. This results in a modular, point and click interface for a lot of design functions such as creating a layout or designing a script. This can make it easy to get started, but in some cases it can be limiting in ways that systems with full up text based script editors are not.


            I've described this key difference to others with the following analogy:


            If Filemaker were a system for creating buildings, FMP is a system where you select various building modules and assemble them to create a finished building. As long as you have a module for every requirement, your building goes up rapidly and you have a happy customer.


            Most other DB systems are more a "build it starting with boards and bricks" approach. This approach usually takes more hours of development and can result in sharply higher development costs. It also is more likely to require experts to create even simple "buildings". On the other hand, in cases where "there's no module for that" in the filemaker system, the "brick and board" systems have a good chance of being able to produce what Filemaker cannot.

            • 3. Re: Working like other RDBMS

              Having a similar background to yourself I can see where you are coming from and finding FMP confusing.


              In short you can take this approach with FMP, however you will of course not have SQL access. In place of SQL you would use Table Occurrences (on the relationship graph) and summary fields. You would access the summary field data through a 1-many relationship from the 1 side, there by allowing you to update a field in the 1-side, or in another table. You would also use Find mode or even global fields as the foreign key in the details table to identify the records to be updated by batch, ie for a specific month, quarter, year, etc.