FileMaker 18 is another important step for the FileMaker Workplace Innovation Platform. It has a nice collection of new capabilities and features that make our jobs as Workplace Innovators even easier. But I like to take these now-yearly releases as an opportunity to step back, look at the bigger picture and fit this release into the broader trends that I see both inside FileMaker, the community and in Workplace Innovation in general.

The Beginning

Two years ago I wrote about how important FileMaker 16 was. I called it the Biggest Change Since FileMaker 7.  We got full cURL support, JSON parsing functions, a REST API and lots of others features that enabled FileMaker to become a first class citizen of the world wide web. It is hard to imagine being able to build apps today without access to those features.  But it was really only the very beginning of what was to become a major transition for FileMaker and the community. We are now well into that transition. In fact I’d say we have reached “The End of the Beginning”

Since FileMaker 16 shipped, several important things have happened or will be happening later this year. They show a company and a community that is more focused than ever and is fully engaged in strategy that I believe has a high chance of success.  Certainly there are challenges, more on this below.  But we are coming out of the awkward 🙂 beginning stage.

First Class Web Citizen

New features are great and individual companies and users can adopt them as soon as they are available.  But practically speaking the ecosystem as a whole is working with an average of the versions that are currently supported. There are still a lot of people using FileMaker 15, which does not support cURL and JSON.  Therefore the whole ecosystem doesn’t get to assume they can use JSON or any other feature in 3rd party products or sharable code, without excluding some portion of the ecosystem players.

Later this year FileMaker 15 will drop out of FileMaker, Inc.’s list of supported versions. All supported versions of the FileMaker Workplace Innovation Platform will be first class citizens of the web, able to integrate with just about any service, API, or app out there.

Modern Cloud Server

FileMaker 18 Server is the first version that has been built with core support for using multiple processors. While some of the benefits of this will take some time become obvious, we need to recognize how important this is.  Re-writing a database engine for a new feature like this is not easy. It’s not like just adding a new script step or a new layout control.  It is messing with a database’s highly optimized core job of writing data to disk correctly.

This had to get done for FileMaker to move fully into the cloud. We now have a server that has the required technical foundations to function as a cloud service or a on-prem server.

Workplace Innovation Platform

I am now into my 3rd decade developing on top of FileMaker and for the first time, I feel that I am in sync with–and have an essential role in–FileMaker’s strategy. FileMaker is and always has been a Workplace Innovation Platform. But there was never a common understanding even within FileMaker, Inc., never mind within the broader community, of what it was. Now there is. The time of figuring out what FileMaker is over, and the time to grow into that category is now in full swing.

We have a new community forum, new hilarious marketing videos, and even a new design on FileMaker front page. The roadmap promises more important changes coming soon. Everything is being shifted and brought into alignment with the new focus on the Workplace Innovation Platform. We even have new changes at the top jobs at FileMaker.

Changes at the Top

Dominique Groupil as CEO kept FileMaker relevant and profitable for two decades, a truly remarkable accomplishment. But even more amazing to me is the fact that he had the foresight to kick off this transformation and make sure it was on the right track before announcing his retirement and turning over the reins to Brad Freitag.

I have had the opportunity to work with Brad on the FBA Partner Council and in various other venues.  He is a good listener. He takes the time to collect and consider many viewpoints before taking action, sometimes bold action. He also has the confidence to course correct when the landscape shifts. In short, I am sure he will do an excellent job in leading the team at FileMaker, and I have high expectations for the years ahead.

The End of the Beginning

The new FileMaker 18 Platform is the world’s leading Workplace Innovation Platform used to help problem solvers address their unique business challenges. It includes great new features for developers to create, share, and integrate custom apps.

It also marks the end of the Beginning of FileMaker’s transformation. We have new features, new marketing strategy even a new management team. The transition is now well underway. Buckle up!

Future Challenges

This all great news. FileMaker needed to rise to the challenge being presented by the market today. In my opinion the challenges that lie ahead have a lot to do with developing the right language to describe what it is that Workplace Innovators have to do everyday. We have a good description of the problems people face trying to use technology to solve problems, and we now have a good set of low level capabilities like cURL, REST, WYSIWYG forms etc. So we know the goal, i.e. where we are trying to go, and we have a good tool that can get us there, but we need to make it even easier for people to pull it off.

Let me put it this way.  In 1995, I could use FileMaker 3 to build a custom information system using the just 6 concepts: Tables, Fields, Layouts, Value Lists, Scripts, and Relationships.  If you understood those six things you could build just about anything you needed at the time.

Today, I have different requirements. Things are lot more complex. I can still do everything I need to do, but it can take a too long to do it myself.  Can we find a way to “compose” new types of objects together so that we can assemble systems faster, using larger teams of people? I am not sure we can ever get back to just needing to know about 6 building blocks. But I believe there is set of modern system design patterns that we can break down, understand and recompose with FileMaker.

For example. Since version 16 FileMaker has had the capability to connect to any API and exchange data. Thats awesome! But once you start down that road you find that it is still a lot of work. We need to make that easier. I say “we” as in we the FileMaker  community and the company. It is up to all of us.

https://www.filemaker.com/learning/devcon/2019/index.html

FileMaker DevCon 2019

I intend to share more thoughts on this topic at the FileMaker DevCon in a couple of months. I am giving two talks on Workplace Innovation Platform. One will be focused on where we are right now. The other presentation will be on where I think we are headed in the next few years.

Also Jeremy Brown is giving a Training Day Session on JavaScript and Geist Interactive is also a conference sponsor. We’ll have an awesome booth. Hope to see you there.

All the best

Todd Geist
CEO, Geist Interactive

Ending a FileMaker transaction is just as important as beginning it. Your script can’t just dribble off into nothingness after the records have been created or edited or deleted. The endgame should be strong. Below I describe how Karbon and the modularfilemaker.org transaction module works. Use any of all parts of it.

As I’ve described earlier, ending the transaction is about trying to commit the changes, reverting back if there’s any error anywhere in the process. Additional clean up can be done at this time as well. Let’s look at how to end a FileMaker transaction.

End the transaction script

In Karbon, we have an “End Transaction” script. It is called after the entire transaction is completed. In our case: when the Estimate and EstimateItems have been copied to Order and OrderItems. Here’s a basic version of the script.

Here’s the basic structure:

  1. Set Error Capture to On
  2. Commit Records/Requests step
  3. Capture the error if there is one
  4. Revert back.

Try to Commit

If all goes well during the actual ‘transacting’ steps (with a portal or without), the intended changes to one or more tables have been completed. Records might have been created or data in some fields of existing records was changed and all the records are held open in the computer’s memory. We now want to push the changes to the actual file and save the changes. So we commit. We try to commit.

The explicit step to commit the changes pushes those changes to the FileMaker file itself. It saves the data. The new records now show up in the file for other users, field values have been edited, and/or records are now gone for other users.

In this step, we also release ownership of any records owned by the transaction process (the newly created or edited record and the parent estimate record). We unlock it so that others may see the changes (edits or new records) and may do their own edits.

In FileMaker, the commit step commits all the records at once; there’s no order in which they’re committed, one after another. They all commit. We can then rely on this feature to ensure that ALL the changes were made in one instant.

The error of the ways

If the commit step throws an error, we then proceed to rolling back. What are those errors? 

Well, since we’re creating records in this case, we’ll most likely get Validation Errors. We will get Validation errors if we are creating or editing records.

The rule is: If your commit would cause any Field Level Validation calculation to fail then your commit will fail.

Rollback changes

If there’s an error anywhere in the process, the transaction model allows the process to rollback the changes made. Since the changes made so far are held in the computer’s memory, any changes made are just discarded. They’re not saved to the file.

Changes that were queued up to be made can throw an error. We talked about that previously. So too can the Commit step here at the end. If there is an error anywhere, we begin the rollback.

In FileMaker we “Revert Record/Request”. This step reverts the current record and all the records changed during the transaction. In our example, if there’s an error and we “Revert” then this estimate and all its lines will not be copied into the Order Table.

ONE NOTE: If onRecordCommit is set on the starting context layout when the commit fails, the trigger will fail, and thus that script will not run.

Clean up

Once we’ve ended the FileMaker transaction, we can do other things to finish this whole process. If we’re using a context such as DBTransactions, then we can add information to the record that describes the  success or failure reason of the transaction. In Karbon and in ModularFileMaker, we have a series of custom functions that get the error and report it back in a JSON object. This information is set into a field for later reviewing.

End FileMaker transactions

Wrapping up the transaction is an important step in the process. Since we’re going to the trouble of doing the transaction anyway, we should follow through and wrap up the process. I would advise also doing the clean up. Log any information you feel it’s important to understand how the transaction committed or rolled back.

 

FileMaker transactions are essential to a well-functioning system. I haven’t stated it for awhile, so I’ll do now. If a scripted process changes (creates, edits, deletes) many records at once, a transaction is required. If a discrete entity (such as invoice and invoice line items) needs to be added or changed in some way, a database transaction is required. We’ve looked at how to do with with portals, but we can do it another way too: FileMaker transactions without portals.

Portals, as we saw in the previous post, are good for debugging and viewing, but they’re un necessary. Chris Irvine, at scalefm.com said something to a group of us chatting late-evening about transactions one day (that’s what I do in my evenings: Talk FileMaker) He said “I avoid using layout objects to do this transaction work”. That’s an interesting idea. Layout objects are user-facing things. Scripted processes should not require any layout objects to do their work. FileMaker is transactional, and through some magic, we can perform transactions from a blank layout. Let’s take a look at how to accomplish FileMaker transactions without portals.

SIDE NOTE: Chris Irvine is a smart FileMaker developer. Be sure you check out his blog posts and his speaking times at FileMaker DevCon.

Start at the very beginning

We’re back at the starting context. In our case, it’s DBTransactions layout based on that same named table occurrence. Here’s what we’ve got.

  • We are on the same DBTransactions layout.
  • The data was gathered and stored as a JSON object in a field.
  • There’s a relationship from DBTransactions and Order, and DBTransactions and OrderItem tables. They’re set to Allow creation of records via relationship”.
  • The relationship is created using a “orderID” and the primary key of the Order table. It’s a similar set up for OrderItem. These two fields in DBTransactions are visible on the layout (though they don’t have to be).

And we are ready.

Here’s the thing

The key to this transaction process is that we’re doing it the same way as with portals. We are creating records through the relationship. That’s all.  We do not traverse a portal to create or edit records. Instead we just set fields across the relationship. We can create the order record and all of the order line items records through their respective relationships without the need for a portal. Let’s pause a second and consider that for a moment. Is your mind blown? (Mine was the first time I saw this happening).

Oh. Another thing

Let’s talk about the relationship I’ve got set up first and establish some ideas about it.

You can see in the picture below my relationship to Order is set up from a field called OrderId and the primary key of the Order table.

That’s not normal. Usually we go from primary key to foreign key. But this relationship is essential to the transaction process. We want one unique record across the relevant relationship each time we’re set to create a record in that table. In a normal primary key to foreign key relationship setup, we’d have multiple related records (as the portal technique shows). We can’t have that. We tap into the power of the Magic key method to set a relationship to each unique record as it’s created. Check out Kevin Frank’s article on the magic key.

FileMaker transactions without portals

Here are our script steps.

Step 1: Create the order record.

In this step we simply set fields in the Order table with the values from, in my case here, the JSON object.

Set Field [ Order::Date ; JSONGetElement (DBTransactions::Data ; “date”) ]

As soon as the first field is set in the Order table, the primary key of that record is generated, and it pops back to the DBTransactions OrderID. The relationship between DBTransactions and the Order record is valid. Setting additional Order fields can commence.

Since a record was just created, our open record count has gone from zero to two:

 
   “OpenRecords”: 
      “DBTransactions”: 1,
      “Order”: 1
   }
}

Step 2: Create first order line item record.

This first order line item record is created very much the same. We set the value of the Order Line Item::amount field with its corresponding value in the first element of the LineItems array. Notice the set up I do before actually setting the field:

And once this field has been set, that OrderLine record’s primary key pops back to The DBTransactions table. There’s a valid relationship to an Order Line Item Record.

And guess how many records are now open. There are three open.

 
   “OpenRecords”: 
      “DBTransactions”:1 ,
      “Order”: 1,
      “OrderItem”: 1
   }
}

Step 3: Create the 2nd and remaining Line Item records.

Here’s where FileMaker transactions without portals gets crazy, so let’s pause a moment and consider what happens next. When I grab the next line item from from the $lineItems (in my example) and I go to set the OrderItem::date field, what is going to happen?

Does the 2nd order line item get created?

BUZZZ!!!

The 2nd line item does not get created because we still have a relationship from DBTransactions to the first order line item record. Setting the OrderItem::amount field with the second order line item’s information from the $lineItems overwrites the first record’s data.

So how do we create a new record in OrderItem? We clear out the DBTransactions::orderItemID field.

Woo. Wait a minute! Won’t that commit the record?

It won’t. For some magic reason, FileMaker keeps that record in its memory. We can’t see that record anymore or access it it, but we can be confident that FileMaker has that record open and uncommitted.

Now that the OrderItemId field is cleared, we can create the 2nd record across the relationship. At this point there are four open records:

 
   “OpenRecords”: 
      “DBTransactions”: 1,
      “Order”: 1,
      “OrderItem”: 2
   }
}

And we keep doing this until all records have been created across the relationship. By the end of the process using my example, I have six records open:

 
   “OpenRecords”: 
      “DBTransactions”: 1,
      “Order”: 1,
      “OrderItem”: 4
   }
}

We keep these open until we end the transaction (coming in the next post).

Transact across the relationship

It’s pretty cool how FileMaker can keep all these records open and in memory when I’ve destroyed the relationship between my starting context and the records. I was blown away when I saw this happening. I swore you needed a portal to create records. But you don’t. You can do FileMaker transactions without portals.

There are a few downsides: For one, you can’t see the records created. You know they were created. Open, but you can’t see them. Secondly. um. I can’t think of another downside. This technique eliminates the UI objects (the portals) to create the records. It’s consistent with our other actions: We can set fields without the field on the layout.

I’d encourage you to try this method. Perform FileMaker transactions without portals. Skip the objects and all that setup and use what FileMaker can do to transact the records. Karbon works this way; Karbon transacts records a lot. So give it a try.

Recently, Dave Graham and Todd Geist led a webinar about Otto, our Dev Opps tool for FileMaker. Watch the video here:

What is Otto?

Todd kicked off the meeting by describing what Developer Ops means. DevOps (as we call it) is anything that will help automate the processes you have to go through when you have to manage a FileMaker Server and FileMaker Applications.

Otto is easy to install on your FileMaker server machines.. And once on the machines, Otto provides many features for the developer:

  • Automated Data Migration
  • Proxy – API keys
  • Config settings that
  • a Developer API

These features and processes are available via your favorite browser. There are some caveats with installing Otto on server machines, and Todd clearly lays those out.

Data migration

In the webinar, Dave demonstrated how to perform quick data migrations using Otto Migrator. He showed how the developer tool does all the work for you when it comes to:

  • Pausing a file on the dev server.
  • Moving a clone of the dev file from the dev server to another server (in this case the production server).
  • Migrating the data from the old production to the clone.
  • Removing the old production file
  • Replacing the old production file with the new production file (the clone)
  • Opening the files on both the development and production servers.

He showed how easy it was to set up the routine to happen at the moment or scheduled for a later time.

Otto Migrator is a great way to reduce all the work that used to take hours into minutes. With Otto Migrator, you don’t need to plan an entire weekend for file transfer and data migration. It is all done while you get that last cup of coffee at the end of the development cycle when a file is ready to be sent to staging.

Todd then continued the webinar by going over the remaining features. Here are the highlights.

Proxy & API Keys

We have wrapped the FileMaker data api in a proxy, allowing us to add Api keys and allows us to connect directly to browsers from anywhere.

Config Settings

Many of the FileMaker Server config settings were removed from the Admin Console, putting them into the command line or the dapi. Otto makes those settings available again. Otto provides a rich, interactive user interface that shows your files’ status, your backups, and even allows you to download any backup.

Built in help

Otto has our documentation built in. There’s also a chat mechanism. Chat with Todd or Dave if there’s an issue and get help immediately!

Put it on your calendar

Todd showed off how a developer can add each schedule and completed migration to your Outlook or Google calendar. The task gives you a lot of details including whether it was successful or not and provides a link to the actual migration log in Otto.

Questions

The session ended with a standard Q & A session. Many of the participants asked great questions, and Todd and Dave took the time to answer.

 

Check out the webinar, and download Otto to try out yourself.

 

 

 

 

 

For quite a few years now, I’ve worked with JavaScript inside of FileMaker. And I’ve tried every possible way to deploy the code from an editor into the custom app. During the implementation of a web viewer widget, I’ve looked on the process with some angst or reluctance. There wasn’t a good way to deploy HTML / CSS / JavaScript into a custom app without building extra tables, fields, relationships. Or the deployment method was such that I couldn’t edit the code in a simple way. In times past, there were a lot of problems in deploying FileMaker web viewer widgets.

WidgetStudio solves the problem of deployment. The developer tool makes it a simple process to deploy a FileMaker web viewer widget that you have customized into any custom app. There’s literally no thinking about it. Click a button, and the code is deployed. Well, there’s a little more to just a button click, but honestly, not much more. Let’s take a look at the types of deployment, the implications of each type, and how easy it is to use any of these methods.

Embedded Web Viewer

Using this method, WidgetStudio actually creates a web viewer object for you and copies it to your clipboard, ready to be pasted onto a layout in your custom app. It is that simple. Watch the GIF below.

Embedded web viewers are good for simple widgets. They’re fast and easy to deploy.

Here are the details

  • I make customizations in WidgetStudio.
    • Since this widget has data coming back to FileMaker, I have the option “FileName”. I make that one “Calculated” which will use Get(FileName) calculation.
    • The widget also needs a script. I hardcoded the script name here “GetDateRange”.
  • I press the “Embedded Web Viewer Button”. The web viewer object (named “web”) is copied to my clipboard.
  • In my custom app, “JobTracking“, I went to the popover where I wanted to place the widget and pasted the object, resized it to make it fit.
  • I then created a script called “GetDateRange”. That will be called from the widget.

Pretty simple. It took me less than a minute to deploy the FileMaker web viewer widget.

The data

The data needed for this FileMaker web viewer widget is either hardcoded or a calculation. And this is found in the Let Statement variable declaration.

The data, highlighted in yellow, can be changed once deployed, or it can be adjusted in WidgetStudio.

Embedded web viewer advantages

This method is advantageous for a few reasons. The widget code is fully contained within the web viewer object. The object can be copied and pasted to other layouts, and the script that is called can be used in other places, or you can point any additional widgets to a different script.

Scripted render

So far in my work with WidgetStudio, I prefer this method. I’d rather let scripts control actions in my custom apps (because I can control the scripts themselves). WidgetStudio offers this option for all widgets.

Essentially WidgetStudio creates an entire script that does the work of compiling the code to run the widget. Watch this:

Here are the details

  • I make customizations in WidgetStudio.
    • Since this widget has data coming back to FileMaker, I have the option “FileName”. I make that one “Calculated”. The file name is gathered at run time with the Get(FileName) function.
    • The widget also needs a script. I hardcoded the script name here “GetDateRange”.
  • I press the “Scripted Rendering”. WidgetStudio copies the steps to my clipboard.
  • In my custom app, “JobTracking“, I went to the popover where I wanted to place the widget and placed a web viewer. I named that web viewer “web”.
  • I pasted the script steps in a script called “Render Date Picker”.
  • On the popover, I added an onObjectEnter trigger to run the “Render Date Picker” script.
  • I then created a script called “GetDateRange”, which will be called from the widget.

The data

As I said before, the beauty of this method is the fact it’s scripted; I can completely control the creation of the data. The data is set at the top of the script.

Though the date & time picker is simple, a complex data need requires a subscript to run. In my pivot table widget, I need a script to gather the data in the correct format and pass it back to this script. Below is a scripted render of a charting widget.

Scripted export

The scripted export method works pretty much the same as the scripted render method, with a few minor differences. This process exports your entire code to your local temp directory and then causes the web viewer object to read from that path. The created script looks like this:

The Details

In order for this method to work, you need to create a container field (invisible or off-layout) that this script can use. In line 18 of the script above, you’d set the field name there.  And again do this in line 52 of the same script.

This method is less useful since it requires a few other steps. I wouldn’t use this method at all except if I use using a widget that involved the FM WebViewer Bridge.

Solving the ‘deploy FileMaker web viewer widget’ problem

WidgetStudio’s three methods of deployment solves the problem of deploying FileMaker web viewer widgets to a custom app. There’s no rolling up of one’s sleeves to begin the arduous of creating schema. Nor are we lacking a place to edit the widget’s code and options. WidgetStudio allows us to deploy a widget in a matter of seconds.

I look back at past files I’ve created to deploy a widget. While they were good for the time and a step in the right direction, I’ll probably never go back to one of those older methods. WidgetStudio’s methods are fast and global.

Give WidgetStudio’s demo a try. Deploy the three included widgets as a test, and see how easily WidgetStudio solves the huge problem of deploying FileMaker web viewer widgets.

 

 

 

Geist Interactive and Carson Lind of Eagle Optimizations, LLC is proud to introduce WidgetStudio – FileMaker WebViewer Widgets that everyone can use.

WidgetStudio makes it easy to use, design and share powerful interface widgets, like calendars, gauges, charts, and timers. Pick from the constantly growing set of included widgets or build your own. Freely share them with your customers or friends.

Get it done quickly!

There is no need to learn any other programming language to use WidgetStudio. If you can design a FileMaker Layout, you can use WidgetStudio’s built in point and click interface to modify the look and feel of the widget. Just few more clicks and your customized widget is embedded into your own FileMaker file, ready to go!

Use your web language skills

If you like JavaScript, HTML and CSS, you will love the familiar built in code editors. Enjoy language specific code formatting, coloring and syntax checking, while you are building or tweaking widgets. When you get it just right, share them with your friends.

FileMaker WebViewer Widget Super Powers

When you use WidgetStudio you get the following super powers:

  • Access to constantly growing set of ready-made widgets
  • A simple user interface for adjusting the look feel and behavior of any widgets
  • Easily embed widgets in your own files with no dependencies
  • Integrated, HTML, CSS and JavaScript code editors for advanced developers
  • A simple and consistent format for sharing widgets with other developers
  • Royalty free redistribution of widgets.

Royalty Free Distribution

You are free to share and distribute the widgets that are included with WidgetStudio in anyway that you want, provided you leave the copyright notice in the generated code in place. There is no runtime dependency on WidgetStudio or any plugin. Once you place a widget into your file, WidgetStudio is no longer required for the Widget to function. It has become part of your solution, and you can use it forever.

An Essential Escape Hatch

The FileMaker Workplace Innovation Platform provides a powerful framework to hang any custom application on. You can get incredibly far without having to resort to advanced techniques and traditional programming languages. But it also has what we call escape hatches, for those times when you need to do something that can’t easily be done with the tools out of the box.

One such escape hatch is the FileMaker Web Viewer. With it we can design any deploy any kind of interface widgets we need to FileMaker Go and FileMaker Pro, using JavaScript, HTML and CSS. It is incredibly powerful and means we never have to say “ we can’t do that “ to our customers. WidgetStudio is designed to make this escape easier to use for everyone, including both the people who want to use widgets and those that want to build them.

Give it a try

Download the WidgetStudio demo and give it a try. With the demo you can

  • Customize the three widgets that are included.
  • Deploy the three included widgets to your custom app.
  • Share the three widgets with others.
  • Create a widget.
  • Download widgets from the library.

See the documentation about the demo for more details.

Join us. Use JavaScript in your custom apps

We’re excited for you to see and use WidgetStudio.  We at Geist Interactive and WidgetStudio’s creator, Carson Lind at Eagle Optimizations, LLC invite you to see what you can make and use.

Join us for a free webinar about Otto, our Automated Deployment and Dev-Ops utility for FileMaker Server. Otto handles the tedious, and error-prone tasks of transferring files to servers and performing data migrations.  If you regularly have to perform data imports and data migrations on your FileMaker systems, you will want to attend this webinar.

Read more

Geist Interactive is releasing a major upgrade to Otto, our powerful Data Migration and Developer Operations tool. Otto automates the complex and error-prone process of migrating and upgrading FileMaker solutions, making it a key component of your Workplace Innovation Platform. Version 1.6 comes with many new features and improvements. There is a free limited license available. Get it now and give a try.

Otto is Data Migration and Developer Operations for FileMaker

Otto is the most powerful Data Migration and Developer Operations tool available for FileMaker Server today. It includes a powerful responsive web user interface, a completely open and unlocked FileMaker file for you to customize as you want, and a full developer API that allows advanced users to create powerful server automations and migrations in any way they see fit.

Version 1.6.0 Highlights

Restore From Backup

If you make a mistake and deploy a broken version of your application, or just need to revert, Otto can restore the previous version, at the click of a button or a through the API.

Redo a Migration

Once you set up migration and run it once you easily repeat that same migration over and over again, with the click of a button in the new Web Interface.

Migration Calendar Subscriptions

You can subscribe to a calendar of all your migration with your favorite calendar application. This makes it easy to see when a migration happened and what the results were in line with the rest of your calendar items.

Saved Versions

You can now configure Otto to use a previously-saved version of a file or files in the migration.  This is great if you need to deploy the same version of a file to many different servers.  Vertical Market solution providers will love this, as it makes it easier to deploy a new version of their solutions to all of their customer’s servers.

New Improved Web Interface

Otto’s web interface has several new useful features. It includes a File Manager for downloading FileMaker backups, migration backups and log files.  It also has much better reporting of migration results making it easier than ever to troubleshoot any problems with configuration or setup.

Other Fixes and Improvements

  • Better Realtime Migration Updates – Improved the migration progress bar visible during the migration, in both the Web UI and Otto Migrator UI
  • Better Error Messaging – Migration results are clearer and easier to understand.
  • Better Pre-migration validation – Otto now pre-validates and warns you if you migration will fail because of mistyped URLs or username and passwords.
  • Easier to Report Issues- You can export a migrations result to a JSON file that can be sent to support for easier tech support and troubleshooting.
  • Better Handling of SSL passwords
    Otto can import, encrypt, and store your SSL Passphrase, without you having to ever log in to an insecure server.
  • Better Large File Support – Very large files would sometimes cause timeouts.

Availability and Pricing

The new version is available now. Pricing starts at $400 (USD) for a 3 server pack and is free for current license holders. You can always download the latest release from your account on our website.

Free Limited Version and Trial

Otto is available in a free version with a slightly limited feature set. The features that are available with the free license do not have a time limit. They are available forever and for free.  See the Otto page for more details and how to get your free license.

Geist Interactive is a sponsor of the CIO/CTO Focus event series in Ventura County California.  The next event will be Feb 19, 2019, and will feature a discussion with leading Chief Information & Chief Technology Officers (CIO & CTOs) from the area. Todd Geist, CEO of Geist Interactive will be moderating the event. If you are CIO or CTO in the area and would like to come, please register using the link below.

Featured Executives

Moderated by Todd Geist, CEO, Geist Interactive

Purpose

The CIO/CTO Focus event series is intended to bring together local executives for an ongoing discussion about the challenges and opportunities facing technology executives today, especially those who are helping to lead companies with significant business operations in the Ventura County area.  The event will be held 4 times a year at a private home in the Thousand Oaks, CA area.

Register and RSVP

You can register at https://cioctofocus.eventbrite.com

Download Flyer – CIO_CTO Focus Invitation

We at Geist Interactive, Barbara, Dave, Lance, Jeremy and Todd (and the ghosts) wish everyone a happy holiday. No matter your celebration plans this season, we wish it to be full of warmth and love and joy.

Thank you for coming along with us as we continue to push what is possible in FileMaker and encourage developers to try out something new.

As a special treat, we are offering an End of Year sale, where every product and package in our store is 20% off.

Use this code: HOLIDAY2018  (colors not necessary) on any purchase and the 20% savings will be applied! It is available now through January 4, 2019, so act fast!

Get yourself or another FileMaker developer one of our products or tools. May we suggest:

  • FMPerception A must have for all FileMaker developers. Its realtime-developer intelligence is unmatched and is extremely useful in your day-to-day development.
  • Implementation packages: Pick up a 3- or 6- or 20-hour package and spend time with one of us to help you through some sticky parts of your solution. We’d be happy to write a few scripts for you as well.
  • Otto. We can’t imagine developing without this tool. Otto is the best tool for migrating files from Development to Production or Development to Staging to Production. It uses the data migration tool.
  • LedgerLink. LedgerLink (formerly fmQBO) is the easiest and most powerful method for keeping FileMaker in sync with QuickBooks Online.

The 2018 year was full of JSON and Karbon and JavaScript and FileMaker for us and for the community in general. Here’s a list of what has happened here and in the FileMaker community.

  • Lance, Todd, and Jeremy spoke at FileMaker DevCon 2018. We also were a diamond sponsor of the event.
  • We released Karbon, our ambitious framework for developing custom apps
  • We defined what we consider to be native FileMaker, and caused quite a discussion about it.
  • FileMaker 17 came out, and with it, features that continue to expand the platform’s limitless possibilities
  • The Workplace Innovation Platform was introduced (our favorite video is “Yoga Balls“).
  • We released a lot of blog posts about FileMaker: Like a Boss, JavaScript, and FileMaker 17.
  • Todd and Jeremy toured the west coast speaking about FileMaker Professional Tools.
  • We released new products: GoDraw3, Editor, Kanban, and have refreshed established ones: LedgerLink and GoZync.

Since we’re in the holiday season, check out Advent of Code 2018. This little event is a great way to refresh your FileMaker development experience. Solve puzzles outside of the normal grind.

And one more thing. Please take a moment to read about One Spark Academy and consider helping this organization.


Here’s wishing you and yours a great holiday season and a prosperous new year. We’re excited about 2019: FileMaker DevCon, FileMaker 18, and more blog posts and techniques, and more pushing what is possible.