11 Replies Latest reply on Dec 2, 2014 7:57 PM by mfero

    Transaction model for FM ...which is "best"


      Hi all,


      I'm new to FM, but have done standard oracle/javascript client coding in the past.


      I'm wanting to implement a phased system for managing my coffee shops (first expense tracking, then staff scheduling, later POS etc). I'll be doing it all in webdirect, and it will be multi-user (staff, partners etc with permission management). It will be handling financial records, so I want an explicit "new"/"modify" "save/cancel" approach to most record creation, instead of the impicit "if you leave this layout it will be saved".


      So I quickly ran into the fact that FM by default has implicit commits and isn't transactional (don't flame me for saying that!).


      A few googles took me into the upteen different solutions for making a standard transactional model (geist, collibri, x, y, z, ...)


      So I've got a simple question (with undoubtedly not so simple answer): what's the "best" (for me at least - small concurrent users, simple DB scheme, webdirect, not FM menus/toolbars) way to implement a transactional based design?





        • 1. Re: Transaction model for FM ...which is "best"

          Todd ( geistinteractive.com ) does a great job explaining how Transactions work in FileMaker.  Not sure there is a really a best way to approach it. As long as you are in the guidelines of what serves as a transaction in FileMaker, and performance is still acceptable when you scale-up...I would say the approach is fine.


          I will caution however, to fully test WebDirect fully before you commit to that route. While I am excited about WebDirect, it's still best suited for simple implementations...and you really have to know how to optimize things in FM to not choke the system. WebDirect, at this point, is very resource intensive. Even for a small number of users.

          • 2. Re: Transaction model for FM ...which is "best"

            Thanks Josh!


            I'm getting their about figuring out how the transactions work, and about 1/4 of the way figuring which is the best way to go about them for what I want.


            It's a pity that filemaker themselves don't provide any clues to this, or tutorials on how to put this together (or write things in a more traditional "kiosk" type mode where people aren't using the FM toolbars etc ...the world has moved on from hypercard!)


            For what I'm looking for right now, the load and number of users would be very small, so I hope webdirect having teething problems won't be an issue.

            • 3. Re: Transaction model for FM ...which is "best"

              The Colibri model is a bit more involved as it relies heavily on trapping the user's interaction on the layout while in "edit" mode.  It's a little more fragile this way.

              It also blurs the line a bit between say an audit-log and transactions.


              I tend to prefer a method where I collect what needs to be changed and then do the batch transaction fully scripted in the background.  This does not rely on trying to capture what the user is doing on the transaction layout because the user never is allowed there.

              In that sense transactions for me are only required for things that must absolutely happen togther or not happen at all.  If I want to just keep track of the changes the user makes, I'll use a more dediccated audit-log approach.

              • 4. Re: Transaction model for FM ...which is "best"

                +1 on scripting (thru the use of globals perhaps?) the "setting" of values without the user being allowed direct add/edit/delete



                • 5. Re: Transaction model for FM ...which is "best"

                  You're talking about copying all the various field values to local script variables and then scripting a batch copy of those values to the record, then an explicit commit right?


                  I saw that approach as well.


                  However in this approach you still need to trap various triggers (most importantly onrecordcommit) to both stop any implicit commits and as a master trigger for your script to copy the data from your variables to the the record then issue a scripted commit etc.


                  So if my thinking is right, this idea still relies quite strongly on trapping the various triggers to avoid implicit commits and trigger the scripted batch commit.  So I'm wondering why you say its maybe more robust than Colibri or Geist's approach's, which still require a lot of trapping, but (simply) use the field UI elements themselves to put the data into the to-be-committed record?

                  • 6. Re: Transaction model for FM ...which is "best"

                    Maybe this is too simple minded... I approached this problem in the past simply by adding some scripted buttons to a page:


                    1) "New" -- Creates a new record

                    2) "Edit" -- Duplicates the current record

                         a) "Save" -- Deletes the original record

                         b) "Cancel" -- Deletes the new record

                    (Obviously you can't let the user change the layout without prompting for Save or Cancel)


                    If iOS devices are not out of the question, I would definitely consider Filemaker Go as opposed to WebDirect.

                    • 7. Re: Transaction model for FM ...which is "best"

                      Have you also disabled the menus to prevent shortcuts or other 'navigation'?



                      • 8. Re: Transaction model for FM ...which is "best"

                        yahbai wrote:


                        You're talking about copying all the various field values to local script variables and then scripting a batch copy of those values to the record, then an explicit commit right?



                        No I don't.  I don't typically have a transaction approach to regular edit mode.  For instance: I don't build a transaction scheme to let the user change a customer or their addresses.

                        But I would build a transaction approach for posting payments against invoices.  For that I build a special "work place" layout where the user can see invoices and enter payment data.  They can't change invoices and the payment data is entered in globals.  I don't have to trap for accidental commits since the new data goes in globals.

                        Navigating to and from this layout and any other actions (like finding a set of invoices, selecting a "payment received" record,...) are all scripted so it is easy to trap if the user has etered payment-applied data without having to resort to a myriad of triggers.


                        If I would want to build an edit mode with transactiona capabilities I would use teh approach that I showed at this year's devcon.  The whole concept is that at the moment that the OnRecordCommit script runs (and it is pre event), the server still has the old data, the client has the new data.  So you can use a PSoS to get the old data if you need it without - again - having to resort to a complex set of difficult-to-maintain triggers

                        • 11. Re: Transaction model for FM ...which is "best"

                          Beverly Voth wrote:

                          Have you also disabled the menus to prevent shortcuts or other 'navigation'?




                          Custom menus to prevent a change in window mode (e.g. to FInd).  One can also hide the toolbar and customize the menus to prevent layout changes or closing a window.  Althernatively an OnLayoutExit script trigger may be used to force the user to "Save" or "Cancel" the newly edited record before navigating away.