App returning different data to different testers

I am testing the latest version of my app in the editor and everything is working fine. However, when a colaborator tests the app returned different data. We are both using the same version of the app, but see different data.

He tried clearing his cache, runing in incognitor mode, doing a hard reset, and running the app as me, no luck. This is consistent, and I see no errors in the log.

My data source is Cloud SQL (MySQL). Has anyone else run into this behavior? How can I diagnore / fix the issue?

yes, happened to me too.

Try using a different browser or a different computer with the same user to understand whether it is a cache problem or that the appsheet data in the cloud that you are accessing is different than the data on each of the terminals.

If there were changes to your SQL table which, for some unknown reason, were not updated to the appsheet server, some users/terminals do not see those changes.

1 Like

By any chance you are using security filters or slices that filters the data differently?

1 Like

Sadly, we are limited to Chrome at my workplace. And the structure of the table is good, it is just the field value that is different..

Not using security filters, and I made sure the slice filters are correct for both users.

Is it only one column value of one row?

Is it a virtual column? If so, what is the App formula expression?

In what view type is the inconsistent value shown? Is it displayed as an editable value?

Is the data in a private table?

Is the data partitioned?

No, it involves four columns. None are virtual columns. One column is editable, the other three read-only. The table is not private, and the data is not partitioned.

1 Like

Do you have duplicate keys? I’m referring to what Appsheet thinks are the keys, not what the databases thinks are.

My key in AppSheet is the same column as the PK in the database table, and there are no dupes.

Please take a screenshot or just explain what are the differences with these 4 columns and take them from one row. What the app shows to you, to the app user and what are values in DB.

1 Like

You have said that you are using slices and that you ‘made sure’ that the slice filters are correct for both users. Do the slices have any time or date components to the filters? Is your collaborator in a different time zone to you?

Let’s have a look at the row filter applied to your slice and can you guarantee that the views you and your collaborator are looking at are both on the same slice?

1 Like

If the expression in the slice would be wrong, it would not then show that row to both of them. So the reason is not the security or slice filter.

1 Like

Here is the correct data, taken from the owner of the app (see blue G). Note the red icon next to the first row, indicating the record is On Hold:

Inside the first record is this populated field:

Here is the incorrect data, take from a different browser (see blue S). The record is not On Hold:

Inside you see that the On Hold is not poulated:

Note that it is a required field, so how could the record exist if the field is not populated? The anser is it is populated, as here is what is in the database:

Interestingly, if the “bad” account sets the On Hold field to Yes and saves the record, the first screen does show the red icon, but only until the record is re-synced.

1 Like

Please post a screenshot of the entire configuration of the affected column.

Here is the On Hold column:




1 Like

Nothing wrong with that. Thanks!

In the app editor, using the app emulator, can you reproduce the behavior using the affected user’s email?

No, whether I am using my email or the other user’s email it works in the editor that owns the app.

1 Like

I experienced the same issue in my case. What worked for me was setting up a stable version of the app.

My suggestion is to establish a stable version of the app - this resolved the problem for me. Hope this can help you!

1 Like

Are you using the new mobile framework preview? If so, try turning it off.

Yes, I am about to do that, but I am a bit worried about it impacting production users.