I have the feeling that when I am updating an unstored calculation in the database definition other users can no longer create new records in this specific table.

I don't know if the "New Record" button becomes disabled, but scripts can no longer create records.

Does anyone else has noticed/seen this behavior?

Thanks in advance !

I have the feeling that when I am updating an unstored calculation in the database definition other users can no longer create new records in this specific table.

I don't know if the "New Record" button becomes disabled, but scripts can no longer create records.

Does anyone else has noticed/seen this behavior?

Thanks in advance !

You have introduced a schema lock by this process. I'd strongly recommend not doing development on hosted files while users are connected.

Steven

In general you should do error trapping and handling after crucial script steps. In this case you'll see an error in the 300 range:

300 File is locked or in use 301 Record is in use by another user 302 Table is in use by another user 303 Database schema is in use by another user 304 Layout is in use by another user

If you can not avoid working in a live environment (and you should try and avoid it), make sure no other users are active. And to be safe, do the error handling so that no crucial processes will fail.

"Other users" may also include server-side script schedules! So either disable those or again do the error handling.

Thanks for the reply!

First of all: I know you shouldn't develop live, but as FileMaker has his data and logic together, there are (bad) reasons to make minor modifications to the logic in the data file (aka live file...)

But still I never saw this behavior before (I saw it 2 months ago for the first time). Was this in previous versions of FileMaker Server already the case? I used to develop a lot in live environment (I know, I know...) and never encountered this behavior, lately we switched 2 customers to FileMaker Server 11, and know I start noticing it. Did FileMaker change something or was I just always lucky? And this lucky would surprise me as we have been heavily working on an invoice module (they were still running on FileMaker Server 10 at that time), and they were invoicing like crazy on the same time (I guess to pay us ). We never had this problem...

But what is bothering me the most: why "only" with unstored calcs? Adapting an auto-enter calculation does not cause this, which would just make more sense as it has an influence on the data. An unstored calc, I am just adapting an operation on the data, not the data itself.

I got bitten by this, too, and now trap for New Record failures (actually loop them), since we often modify Live. I can't remember where I read this (could be Todd Geist's blog, as he often addresses approaches to robust scripting), but it's not the unstored calc. I believe I've read that it is the fact that you are modifying a table that has an auto-enter serial, and therefore FM is preventing New Records bcs it needs that next serial number and it can't get it. Welcome to Table Lock.

Hi Bcooney,

that is the exact answer I needed! It is true, it is the auto-enter Serial Number that is causing it...