Good day. I'm seeing a very odd - and potentially disturbing - behavior with Go on my iPad. Here's the scenario:
I have a solution that serves as the back end for a web site. Recently, I added some charts to the solution. For each chart, I have a container field in parallel (so I can use containerBridge.php to display the chart on the CWP page). I have an OnRecordLoad script trigger set to refresh the charts on a particular layout.
Okay, with that setup, it works pretty well on the FileMaker client. I was doing some updates of text fields on the layout with the triggers on my iPad day before yesterday, and when I exited the database, it started doing a "Compacting database, please wait" thing. Not being used to that, I hit the Home button without catching what I was doing. Oops. So I went back into Go and ... it was frozen. Forced it to quit, started it again, and it gave me this nasty message:
"The database (X) has been damaged and cannot be opened. Use the Recover command in the desktop client to recover the file."
So, I'm thinking I broke it by interrupting the Compact process. Go to a backup, say a few nasty things to myself for being stupid, and shrug over lost data. Move to yesterday, do it again. This time, we let the Compact process finish. Don't even exit Go, try to open the database and ... it still reports being damaged.
Go to the desktop client, and, lo and behold, it really is damaged. Run Recover, comes back saying the recovered copy is safe to use. The only thing the Recover did was remove one block that it says wasn't damaged, but ... we're still going to a backup.
This is weird. Running FM 12, Go 12, Mac OS 10 Snow Leopard. My update script basically sets a trigger field for an Evaluate that copies the chart object into the container (3 of them on this layout) using GetLayoutObjectAttribute.
Any ideas? Has anyone seen this behavior? For now, I'm just avoiding doing these triggers on the iPad, but if I'm doing something wrong, it'd be good to know. Or, if I've located something broken inside the Go engine, well, that'd be good to know too.