Error 200 when deleting a record

1

I'm encountering a strange issue and could use some advice. I have a script that commits a record and then deletes it without dialogue. However, when I run the script in the debugger, I consistently get Error 200 (Record access is denied).

Here’s what I’ve done so far:

  • I’ve verified that the script runs with Full Access privileges.
  • The user executing the script also has a privilege set with delete rights for the table.
  • I checked the relationships, and I don’t think that’s the issue. The record isn’t locked or related in a way that should prevent deletion.

This is my first time seeing Error 200, and a Google search mentioned relationships or privilege issues, but I’ve ruled those out (or so I think).

Does anyone have tips for debugging this or suggestions on what else to check? Thanks in advance!

2

I suggest you show your script, that would help us figure what is going on.

1 Like
3

The issue here is likely that once the record is created, you remain on that UNCOMMITTED record which is locked open.

Add a commit after creation and it should work

1 Like
4

Kirks Idea seemed to do the trick!

5

Opening this back up. The user has full access, it is not a commit record problem, the error 200 suggest the user wouldn't have access to the table. Does anybody have any ideas

6

You say the user has delete rights. Do they also have Create rights?

7

Yes the user has Create rights. One File lets say DM- is connected to another file called Web, would this prevent the user from deleting a record in the file DM?
(assuming the user has full access privileges in DM but not Web)

8

@Drew Are there any settings in the underlying security model; the area where you can restrict privileges on a field, record, or layout, based on some calculation, where you might have delete restrictions on?

This extremely powerful and well obfuscated area of FM is not necessarily intuitive and clearly reflects the "with great power comes great responsibility". So many times, I've set conditions in the security model, and months later, tried to find the source of a problem only to finally discover it was a setting in that security model that I completely forgot about (I wish FM would set a more obvious flag in the privileges indicating that something/anything is set in that underlying area, so it would be a clue to look. That clue shows in the drop down as "custom privileges" in the privilege details for layouts, scripts, tables, etc. ).

A 200 error could easily be a result of a setting there..........

9

I think I know what you are referring to.
Are you saying within the security menu, you can restrict tables, and fields?
If so, then there weren’t any restrictions there.

However the file was connected to another file, which we then added full access for the user in the second file. This SEEMS to have solved our issue.

(Is this a cascading delete?)

10

TO - table occurrence.

A cascading delete is a record deletion that occurs in TO B when you delete a record in TO A. This is something you define in relationship graphs.

Note, and this is important, that TO A doesn't need to be in context to perform cascading deletions. If a record of TO A is itself the subject of a cascading deletion, then whatever cascading deletion rules are defined for TO A will take place. This also applies across multiple files.

Hope this helps.

2 Likes
11

That makes sense, thank you for taking the time to explain