Delete action throws TableRefMetaData error

AppSheet AppSheet Q&A
, ,
1

Hi @Jose_Arteaga @Shourya_Tomar ,

I’m encountering an error when attempting to delete a record from the TRANSACTION table in AppSheet. The delete action appears to complete locally, but the app fails during sync with the following error:

Unable to delete row from table ‘TRANSACTION’. → Unable to cast object of type ‘TableRefMetaData’ to type ‘EnumMetaData’.

Screenshot 2026-06-19 at 12.23.10 PM
Screenshot 2026-06-19 at 12.23.10 PM1920×1249 188 KB

I’ve already regenerated the schema for the TRANSACTION table and all the child tables, but the issue persists. The error suggests AppSheet may be expecting an Enum/EnumList column somewhere in the delete process but is instead encountering a Ref column definition.

Has anyone encountered this specific error before or have suggestions on where to look next?

2

This is an internal error. Please contact Support for help with it.

3

Hello @yugal.one,

I would like you to try this first if you do not mind: There is a data type mismatch, it looks like AppSheet is expecting to process a column as a simple dropdown list (EnumMetaData), but the underlying column definition or value is behaving like a table reference (TableRefMetaData).

This usually happens when a Ref column is configured as an Enum, or when a background action tries to pass a reference value into a standard text dropdown during a deletion.

Troubleshooting Steps

  • Check for “Ref” Columns Configured as “Enum”
    Go to Data > Columns and open your TRANSACTION table settings.
    • Look closely at any columns set to Enum or EnumList to see if their Base Type is set to Ref.
    • The Fix: If you spot one, double-check that the “Referenced Table” is correctly mapped. If the column is just supposed to be a standard, static dropdown list, change that Base Type from Ref to Text.
  • Check your Virtual Columns. Look for any dereference expressions (e.g., [Related ID].[Status]). If that expression pulls from an Enum column but the app treats the output as a Ref, it can also trigger an error.

Otherwise I agree with Steve, the best option would be to Contact Support.

4

open my all account

5

Hey @Jose_Arteaga

Thanks for the suggestions. I tried going through the troubleshooting steps you mentioned, but I couldn’t identify any abnormalities or root causes on my end as of now.

It looks like AppSheet support has now been merged with Google Workspace support. When visiting the AppSheet support page and clicking “Contact us,” it redirects directly to the Google Workspace support page.

I went ahead and opened a ticket through there.

Ticket ID: 72440945

6

I understand.

Please let me know if there is anything we can do to help.

7

Hi @Jose_Arteaga,

I am following up on this issue with the results of some isolated tests I recently performed.

I tested the app on the TRANSACTION parent table with all three of its child tables: MOVEMENT, PROCESS, and JOURNAL. I can confirm that if a record is present in any of the child tables, the delete action for the parent throws the error.

To determine if other tables are also affected, I tested this with additional tables that share a parent-child relationship. Specifically:

  • CONTACT (parent) and CONTACTGST (child)

  • BOM (parent) and BOML (child)

  • PHSTOCK (parent) and PHSTOCKL (child)

All of the above cases are throwing the exact same error.

Additionally, I observed the following behaviors during my testing:

  • Deleting each child record independently does not throw an error.

  • The moment I uncheck “Is part of”, the parent record deletes successfully, but the child record remains orphaned in the child table.

I have documented all test runs, error logs, and screen recordings. I also have screenshots and logs regarding a recent editor-level error - Error ID: 93193 that may share the same root cause.

Since these files contain sensitive app data, I would rather not share them on a public thread. Please send me a DM so I can provide the Google Drive links for your further investigation.

8

@yugal.one and @Jose_Arteaga ,

If I may join the discussion and share my observations. Based on the latest details shared by @yugal.one , it sounds that the delete action on parent is failing for him when there are children with “IsPartOf” relationship for that parent table.

I quickly tested on a test app having “IsPartOf” parent child table relationship. However in my case the deletes in the parent as well as related child records seamlessly took place as expected. Deleting parent record deleted that parent record as well as all of its children records.

9

Hi @Suvrutt_Gurjar ,

Thanks for looking into this! Just to provide a bit more context, everything in the app was working perfectly fine until I suddenly noticed this issue a couple of days back. I don’t remember making any such change that might impact this action or the table relationships immediately prior to this TableRefMetaData error popping up during the delete action.

10

Hi @yugal.one ,

Thanks. Then I believe it is what Steve has already mentioned.

11

@yugal.one, did you get this worked-out?

12

Hi @Steve

Thanks for checking in. Unfortunately, the issue is still not resolved.

I actually had a meeting with the Google Workspace support team this evening to troubleshoot this further. After reviewing the app and the schema alongside my isolated test results, they were also unable to resolve the issue on their end.

Because of this, they are now escalating and transferring the case directly to the AppSheet engineering team for a deeper technical investigation. I have already shared the app details, screen recordings, and audit logs with them so they can investigate the backend.

13

I’m glad it was escalated. Please keep us informed.

14

Hi @Jose_Arteaga @Steve @Suvrutt_Gurjar

I managed to track down the root cause of this error with the help of Google Workspace support and wanted to share the complete context and solution.

Root cause

It turns out the exact issue occurs when the child table (ie, tables having a reference with “Is part of” enabled) has its Key column data type set to ENUM. AppSheet struggles with the cascading delete in this specific configuration, which is what throws the TableRefMetaData type casting error.

Fix

The fix is straightforward: avoid using ENUM data type for the Key column. The Key column should ideally be set to standard types like Text. After updating my child tables to use Text for the Key column, the delete action completes and syncs perfectly.

Why use ENUM for these columns in the first place?

You might be wondering why I had the Key column set to ENUM instead of Text. I actually use the ENUM data type for almost all of my standard text columns (setting the Base type to Text, Name, Email, etc, further allowing users to add new values).

The primary reason is better native filtering. If you use standard data types (Text, Name, Email), the native AppSheet filter usually just provides a blank text box, requiring the user to type out exactly what they are looking for. However, by formatting these columns as ENUM, the native filter automatically allows users to select specific existing record values from a dropdown list. This makes filtering significantly faster and more intuitive for the end user, as they don’t have to manually guess the exact spelling of the data.

While the ENUM workaround is great for filtering standard columns, it seems it simply won’t be possible to use ENUM for Key columns—especially on child tables that have “Is part of” enabled.

Hopefully, this helps anyone else who encounters this specific error in the future!

15

Thank you very much @yugal.one for your update with the detailed explanation.:clap:

Really appreciate it. Such concluding updates definitely help any future reader of the post thread.

Key (a little pun intended :slightly_smiling_face:) takeaway from your post is " not to set a key column to enum type but a text type is the most preferred option."

Thanks are due to the Google workspace support team also who helped you solve it.

16

Glad you were able to get it fixed, and thank you for the excellent explanation!