vince.menanno

Error Logging and Data Migration Tool

Discussion created by vince.menanno on Jun 18, 2018
Latest reply on Jun 18, 2018 by beverly

I am looking forward to making use of the Data Migration Tool in our projects. We have been discussing internally how our process will change and how we ( along with the client/customer ) go about validating that everything is working as expected before we roll out new features.

 

Once we are done with development we could switch gears and test out our work. One possible way might be to look at the event log for any errors encountered during our testing. However, there is a problem with using the event log. The event log will only log errors for scripts that run on the server. None of your connected clients ( using Pro or Go ), will log script step errors. In my opinion this is a huge shortcoming and must be addressed.

 


 

There is only so much error checking one can might do in a script. Here is a snippet of code that includes some error checking - it captures if there are no records found and exits the loop ( not shown i the snippet ).

I put red dots on places where one might want to also trap for some potential errors.

Line 13 what if the parameter passed in was empty

Line 17 what if during data migration we inadvertently deleted the Layout

Line 30 what if the relationship is missing and no data is returned into the $_id_job variable

Line 31 what if we changed the permissions or added a new privilege set and the user wasn’t allowed to delete the record

Line 34 what if the script was deleted

 

Screen Shot 2018-06-18 at 11.56.14 AM.png

 

As we review code we might find that we need to add more code in certain places to make sure that we have data to work with. However in the example below I would argue that I might not want to trap for an error on going to the layout. Instead knowing that we ran through all our tests and everything succeeded successfully that would be great.

I would also not want to make the script filled with all kinds of additional error checks on things that might not be needed.

So this script could quickly turn into a mini-monster and with all the added error checking one would loose the flow of the script.

 

That is why we really need some new ways to work with detecting errors… here are a few ideas.

1. What if there was an internal table that logged all these errors for us. Who ran what script, when, how long did it take to run and what were the errors it encountered and on what step number were those errors.

2. What if the event log had the ability to also capture the script step errors when a user who is connected to a hosted file encounters and error

3. What if we had a Try block and we could capture all the errors encountered ( what step number and what the error number was )

With idea #2 every time I have mentioned this to someone at FMI - the concern was always about performance. It would be a lot of data and that it would add more traffic and would slow things down. I would argue that this data is essential to us and that we should have a way to turn on minimal or verbose logging on a file by file basis.

Especially now that we’ll have the ability to run 3 instances of FileMaker Server

• Development

• Q/A Test

• Production

Now it seems to be even more appropriate and urgent of a need.

With minimal logging, any client connected the server and runs a script where a step encounters an error, it would be logged.

With verbose logging then the duration of the entire script could be logged along with every step that uncounted an error.

And yes this would add more traffic and can slow things down over the network, but ideally one would only turn these options on the Development and Q/A Test Server.

This would be incredibly useful information, both for ensuring quality and improving/understanding performance.

I would invite you all to consider what new ideas and capabilities we might need now that we have data migration tool at our disposal.

Here are a couple of ideas to upvote ( some I have drafted and some others have drafted )… but that relate to this topic.

 

Get ( ScriptStepErrors )

 

Logging all script errors

Get ( ScriptStepErrors )

 

Try ... On Error ... End Try

 

If we have this ability to turn on error logging and profiling at the file then maybe at the top in the menu bar a little bug icon could show up. To let us know that debugging is turned on.

 

In summary I think giving us some method to log script step errors for logged in Pro and Go clients is a must at this point. Thanks for reading and up-voting.

 

Vince

Outcomes