LinkedIn
Twitter
We are in need of some advice in lieu of any input from AppSheet's engineers on a ticket raised via the 'Support' link.
For the last several weeks, we have noticed that PDF reports state inaccurate dates, typically 24 hours behind the actual date submitted or when the app was last used. This is occurring across all apps, of which we have several running at any one time and none of them have been modified in any way whatsoever for a long time.
Typically, the apps will have a default condition of [DATE] = TODAY() to fire the report and for speed, cells in the input spreadsheet will reference one other, written as '=$(cell)$(number)'. These bots have updates, adds and deletes enabled.
The two snips below illustrate the email received indicating the correct date and that of the report issued which shows the date wrongly, in this instance the date when the app was last used.
Has anyone any ideas on how to resolve this as painlessly as possible? As mentioned, there has been no worthwhile input from raising a ticket and online chat degenerates into the nuclear option of creating a custom template via AppSheet which, to be fair, works to a degree but would ultimately require redesigning a whole tranche of output templates which seems excessive and unfair as the issue does not emanate from our side.
Hi Aleksi. The bots are triggered by data change. We have resolved one by turning it into an email report as an attachment isn't strictly necessary; however, the others need to be PDF reports as they contain a number of fields:
The ID field is controlled via a referenced cell whose formula is =DEC2HEX(RANDBETWEEN(0, 4294967295), 8). This has been in existence on the app for some time and has not created any issues, but just to avoid another question and waiting for a response.
The problem is also present in the same way on an entirely separate suite of apps, again triggered by data change and with the condition of [DATE] = TODAY(). These have been in use for well over a year without update.
Hi Aleksi. Yes, it is a rather large problem! Google's engineers have made contact but only at a basic level of enquiry.
The [DATE] = TODAY() is correct, I showed a sample of a template, apologies. Below is a real-life screengrab:
Here is the desktop display of the app as it can be viewed on a mobile device at this very moment:
Here's the email notification:
This is the PDF report, you will see that the date is wrong:
And here we have the basic setup of the bot:
Please note that the above illustrates the problem with three similar apps. We have another suite for different activities but using the same build-up/architecture/theory so in all we have about a dozen apps which are failing daily.
It is, isn't it? Just singular key columns, as shown below:
As noted before, no changes to these arrangements for months, certainly a long time before the issue started presenting itself.
I haven't tried the Start/End idea (assuming that it would be written as follows, if not please correct me) as there's so much data to capture and I'm not sure about legibility. I can try though:
Check: <<[Check]>>
ID: <<[ID]>>
Description: <<[Description]>>
Response: <<[Response]>>
State: <<[State]>>
Notes: <<[Notes]>>
Signed: <<[Signed]>>
Date: <<[Date]>>
Tried that and I get the following errors in a fresh app, purged of all other bots etc:
Which is plainly stupid, because the table is told to point to this sheet and the Excel file has the correct name, plus the logic has been copied into the email body as advised:
Now corrected, this is the resulting report:
Updated to <<Start: SELECT(Daily plant inspection[Check],ISNOTBLANK([Description]))>><<[Check]>> and that appears to work, so success there.
The other apps, written as <<Start: SELECT(Checks[Check],ISNOTBLANK([Description]))>><<[Check]>> and are otherwise set up as below; the table Checks is also cited in all elements of the bot, same as the other:
