Auto deleting child with "Is a part of" not working

I have several child tables that need to have related data deleted when a parent row is deleted. All tables are deleting data properly with the “Is a part of” REF link except for one. The only thing I can think of is that something about the way this table is populated (by an “add a new row to another table using values from this row” action) obscures the child relationship.

“Is a part of” is selected only in the User column.

Any thoughts?

Solved Solved
0 15 953
1 ACCEPTED SOLUTION

Is “user” table reffed to another table too ?

I would also check in User column for suspicios stuff, like spreadsheet formula remainings etc.

The name of the Gsheet and table, perhaps it doesn’t like the underline.

Maybe even delete and recreate the category dash table, in worksheet and in appsheet, without VCs, without underline. Then test the delete. Then add one vc,retest, second VC,restest…

View solution in original post

15 REPLIES 15

Is the behavior identical if you reverse, I.e., make Category is part of?

I just changed the is part of from User to Category, created a new category and deleted it, and still no delete on the Category_Dash table…

Then, I would say it is a bug (or missing feature) to be sent to support@appsheet.com

The auto-deletion works for me as of just a couple days ago. And that was also in a case where I’d used the same action type as you described to originally create the child records. Are you making sure that you’re letting the app completely sync?

Yes, it’s had plenty of time to sync. The other child tables are working properly, for some reason this is the only one that’s not. Very strange, I’ll send a request to the support team.

Is it possible that your client has not yet downloaded the most recent version of the application that includes all of your changes?

If a client device has any queued changes, those changes will be processed using the version of the application that was current when the client last synced. When the client submits its changes, it includes the version of the application that was active at the time the changes were queued. The server processes those changes using the version of the application the client included in the request. If that is an old version, then the server applies the change in conformance with that old version.

You can check the version being used by looking at the Audit History. The version number will be displayed with the incoming Add, Update, or Delete request submitted by the client. Compare that with the latest version of your application to see if the latest version is being used.

In this case I am the client. I’ve recently deleted and reinstalled the app on my phone, and obviously every time I load it up on the browser it’s loading up the most recent version.

Why is this obvious?

Actually, the browser version tends to be very “sticky” in regards to caching older versions of the app and NOT using the most recent version. I recommend forcing your browser to refresh with Ctrl-F5, then follow it up by a manual sync. Do that EVERY time that you open the browser app while the app is in heavy development.

Great suggestion, didn’t realize that.

Is “user” table reffed to another table too ?

I would also check in User column for suspicios stuff, like spreadsheet formula remainings etc.

The name of the Gsheet and table, perhaps it doesn’t like the underline.

Maybe even delete and recreate the category dash table, in worksheet and in appsheet, without VCs, without underline. Then test the delete. Then add one vc,retest, second VC,restest…

Deleting and recreating CategoryDash solved the problem. It was a pain, but well worth the effort. Thanks for the help!

Hi Paul,

If neither my suggestion nor Marc’s resolve the problem, I suggest you submit a bug report.

If you do that please include:

  1. Your numeric account id
  2. The app name
  3. The exact steps to reproduce the problem.

@Phil, could you please add this to the documentation so other users may benefit?
Thanks.

Not sure exactly what I did to fix it other than delete the table and recreate it. Could you be more specific about what you’d like me to add?

Maybe you encountered a “one of” case but I was asking Phil from the AppSheet team to add a note to the documentation (not sure which page) that for others who may see this same behavior that you did, the steps that they should try to fix it.

Top Labels in this Space