Hello!

I have a solution many years in development for theatrical lighting data management. I'm working to implement some new features and before I dive too far into experimentation, I'm hoping someone might have some insight here. 

This solution is using MBS plugins, specifically the Socket.Read function, to receive incoming messages from a lighting controller. (Reading OSC from an Eos, if you are a lighting person) What I'd like to be able to do is to save each incoming message to a table in the background, in a way that doesn't affect what the local user is doing. The problem, of course, is that if I get 20 incoming strings, it takes a moment for FM to create those 20 records and in the meantime, the local user's FM hangs for a moment and won't allow them to do anything else. Then there's not much processing I can do with this incoming information because it would cause a further delay before the local user could get back to what they were doing.

Am I correct that there's really no way around this, since FileMaker is single-threaded? I wish there was a way to automate this in the background.

I'm going to experiment with this soon, but I'm also wondering if it affects clients as well as a host - for example, if all this data gets sent to the host computer, will it hang client computers? I'd think that the clients should be unaffected. 

Thanks

Mike

Why not run the routine as PSOS with out waiting for return. It could go off and create the records server side.

 

Just now, Ocean West said:

Why not run the routine as PSOS with out waiting for return. It could go off and create the records server side.

 

I had that thought, but unfortunately in this situation, we're not always able to use FMS. 

You could install FMS on the computer onsite and then users could be guest of that host.

 

 

2 minutes ago, Ocean West said:

You could install FMS on the computer onsite and then users could be guest of that host.

 

Unfortunately while it could work in theory, it often times would be impossible for our particular use case - we often need to be able to work in the database while local in the theatre, but also then be able to work on it at Panera or at our hotels without having to move equipment, so having just the .fmp12 file in dropbox is the way we have to go. We typically don't have any control over the WAN side of things at the theatres we work in, so we wouldn't be able to make the server publicly available. 

Typically in pre-production, the file is hosted on my AWS FMS and everyone can login to it. But once we're onsite, it gets pulled down and hosted locally from one of the team's computers because we can't trust show-critical data to an unknown internet connection.