are there still speed and sync issues happening with the appsheet servers?
last night and this morning my app has been taking a very long time to sync.
quick edit changes don’t seem to reflect right away on all views, and sometimes new views seem to not configure properly and need to be deleted and recreated to appear right.
Hmm, I have not seen any odd behaviors or slow performance myself today!? @Aleksi_Alkio @praveen @Adam_Stone @Morgan_Dixon_AppShee
Could you let us know what time zone you are in and the approximate time window you have had such experiences?
thank you both for looking at the issue.
i see a lot of uses for report type views that have several calculation columns for lists of values.
statistics on clients, hours/benefits tracking for lists of employees, lots of different ways to generate real-time reports on supplies.
is there a way to cheat?
such as do all the calculations in the google sheet and trigger refreshing the page with a sync from an action like saving after changing the date range?
If you have network connectivity and automatic sync turned on, any edits you make to the prices or the date range or whatever else should trigger a background sync to start, and that should update all of the virtual columns when it finishes - usually within a few seconds. So trying to force the update to happen within the app may be more trouble than it’s worth. But it does seem like there ought to be a way to make it happen.
@Adam_Stone you bring up a good point, it syncs right away, i’m just trying to get around the user having to refresh the page.
right now i am thinking, as work around, to create a table that is just a report page with a bunch of buttons, the first button lets them set the date range, and then directs them back to that table as a menu.
the remaining buttons will have the individual reports.
hopefully this will allow the sync to happen fast enough without having them going back and forth within a dashboard.
The page should refresh automatically when the sync finishes. Do you have the Delta Sync option enabled? I wonder if that’s the reason you don’t see the VCs update even though a sync occurs. Because Delta Sync checks the last modified time of the sheet to decide whether to send the table again, but virtual columns don’t get saved to the sheet, so if the only changes occur in virtual columns they may be missed.
@Adam_Stone i did have Delta Sync on for speed.
i will change that and experiment some more.
thanks for the suggestion!
Sure, thank you.
I am east coast US.
I was working on the app late last night and again this morning.
there were a lot of seemingly little issues, I am not entirely sure how much are related simply to the debugging process as I am not an expert yet in appsheet formulas and behavior.
I have been seeing much longer than normal sync, save, and save + verify data times.
3 to 4 times as long as normal.
At least one-time last night I had to walk away from it for an hour because it just wouldn’t load the app.
This was around 10pm I think.
I also had to recreate a view a couple of times.
I was trying to and begin and end date fields to Quickedit
in a detail view.
The table only had 3 columns, a key field I put in, begin date, end date.
The view would not let me add the begin date.
I checked it multiple times to make sure it wasn’t the index field.
I deleted and recreated the view + removed and re-added the table and it did not help.
this morning when I went back to it, same problem, but when I removed and re-added it this time it worked.
The current issue is with a dashboard.
When I change the begin and end dates on my new view, the table next to it in the dashboard that uses those fields in a select formula takes about 5-10 minutes to update itself.
The dashboard is set to interactive.
At first, I thought it wasn’t doing anything, but I left it up on the screen, it eventually changed.
@Seth_Berman I checked the reasons a column might not show up as eligible for QuickEdit: - is marked Read-Only - is marked Hidden - uses an AppFormula or sheet formula - is a ChangeTimestamp, ChangeCounter, or ChangeLocation type - is the key column or a system column (like row number) - is used in a computed key - is excluded from the slice - is excluded from the view (omitted from ColumnOrder)
Maybe one of these conditions was accidentally met? If it happens again, we can investigate exactly why it’s not showing up.
For the dashboard, it sounds like the view is not updating until the next background sync occurs. Is the Select formula on a virtual column? When a row is edited, the app will try to update virtual columns immediately in any rows that have a Ref column pointing to the row that was edited. But rows in other tables that only have indirect references through things like Select or Lookup won’t update until the next sync.
So one way to force an immediate update is to make sure there is an explicit Ref relationship between the rows. But making the edit should also trigger a sync to start. Since you’re noticing long sync times as well, probably the delay you saw was the time it took to complete a sync. It’s possible there was a problem with one of the servers, but if you’re still seeing slow sync times it might be worth digging into the performance profile to see where the time is spent.
Performance Profile help.appsheet.com
Adam,
thanks for your fast response!
i tried every conceivable way to configure the missing column, so i am pretty sure that was just being buggy.
if it happens again i will leave it and post so someone can see.
the information about the dashboard and quick-edit updates is interesting.
i like getting a better idea about the rules in the system.
i haven’t done anything with REF columns yet and have been using mostly SELECT and FILTER expressions for what i need.
i have a question about making an explicit reference.
if i create a VC on the report table and make it type REF and point it at the data table, it will return the value of the data table KEY correct?
is that reference sufficient to trigger the faster priority sync with the SELECT expression?
i wont be able to work on this again until tonight some time.
i will check the syncing times then.
The values of a Ref column in the underlying data should match key column values in the referenced table in order to actually ‘find’ the referenced row (since the key identifies the row). Since keys are often not meaningful for end-users, within the app UI a Ref will display the “row label” column instead (which may not be unique).
You could add the Ref as a virtual column, but you’d need an AppFormula that finds the right row key. Can you explain a bit more the scenario? You have a data table and a report table, about how many rows are in each? Is the Select on the report table searching the data table, or vice versa? And what does the full Select look like?
So the app has a form where orders are placed.
this populates the data table, which includes a Key row that is just a sequence of ascending numbers, an order datetime, client name,
product, ordernumber, etc.
the report table includes a list of clients, a similarly structured key column, and VCs containing the SELECT queries.
the challenge has been creating a report that can total all sales for each client in a given date range.
i originally had the begin and end dates in the report table, but moved them to a separate table so that i could have the end users edit these values in a dashboard in detail view, while the report table could use table view.
=SUM(
SELECT(
Orders Table[Order Cost], AND(
[_THISROW].[Client]=[Client],
[Date] >=ANY(Date
Range[Begin Date]),
[Date] < ANY(Date Range[End Date])
)
) )
Thanks, that clarifies a lot. It also makes this trick a little harder to pull off, though, because now the formula depends on columns in two different tables. Let me think on this a bit and get back to you tomorrow.
@Adam_Stone Thanks!
i appreciate your time.
I would happily lose the date range table if i can figure out a clean way in the UI for the user to change dates and view the data in a table view so they don’t have to jump through slides.
Yesterday I was thinking of using a slice to filter the date range, but I realized the same problem occurs for virtual columns with app formulas involving slices - if a data change affects the slice filter condition, although the view will update with the new filtered set, virtual columns that do something like a sum over the slice won’t immediately recompute. So ultimately, I don’t see a way to get this to work with how these virtual column updates are currently handled. If it’s a single row doing the aggregate it could be done, but having a separate aggregate on each report means there’s no way for one row to Ref them all at once. @praveen let’s discuss whether we can expand the criteria for updating virtual columns on the device when something changes.