Title says it all. The CSV upload should work for tables that only allow adds, but the button is missing until you enable updates too.
In case we pass the same key value(s) in CSV file and import, then Appsheet naturally update (or overwrite) the exsisting rows on Import CSV actions. In that sense, it is naturall we need to set table Add and Update.
Yes, it makes sense for certain cases, but there could be times when importing to an ‘ADDs ONLY’ table is desirable.
I was thinking of a temporary “Import” table that is JUST for storing raw import data. This would then be reviewed/approved by a different user, and the data would be copied over to the permanent table-- but NEVER edited. It my use-case, I actually want to ensure edits are NOT possible, but could really use the CSV import feature.
Your requirement is quite understandable, you want to implement one step before the raw data is added to table which is in production after the appropriate personnel review the data rather than all the CVS rows are appended to production table straight away to avoid the unexpected rows are added to table.
Hearing your requirement, I come up with arrangement like this, although I m yet testing my idea.
We prepare the intermidiate / independent table to import the data by CSV import action, actually exactly same data schema as the target/final production table.
Then we also prepare another qimple and quite table. This quick table will solely stands as parent table for the above mentioned table. We simply add one row to this table with required fields, but ID / key value of ROW1 as text.
For the intermediate table, we also add “parent”, which will ref to above table. Then set this parent field initial value to ROW1.
On the CSV import action, we dont need to add Parent field in the CSV file / field , as Appsheet will automatically push stamp of ROW1 through initial value set up.
Once we open the ROW1 in detail view for parent table, then we will see the inline-child rows for intermediate table, no matter what of data are IMPORTED through the CSV import action.
The appropriate user will access to this detail table for REVIEW the contents. Once he / she is happy with the data, then press the action button associated to parent table.
This aciton will do following jobs.
- copy each row to production table.
- delete row value after 1) action is fired.
By single hit of parent action button, this action will be applied to all the rows in the intermediate table.
Once jobs are done, the temp table will be completely cleared out, and inline view will show nil row, but we will see all the rows in the productoin table.
In addtion to copy and delete action, probably we are able to introduce action to DELETE ALL the rows assuming the case where the user want to completely truncate the temp table due to uploading/importing data wrongly and wanna start frm the first step, i.e. import CSV from the scratch.
Also it may make app heavier, but we could add VC in temp table for validation test. with in expression, if or not the row and id in temp table will have duplicate row in the production table, and if there is, throw alert through the format rule etc?
Ok, I was lost until I got to the second half and saw where you are going with this lol. It’s actually a really cool technique. But it’s a lot of setup, and I’m just building a one-time migration tool.
I’m looking for a minimal effort way to build this one-time tool, and a simple fix on the display settings of the overlay for ADD_ONLY tables would be much more preferable in this case.
I will be saving this idea for other projects, though! Thanks for the idea.
Phil in Appsheet should have been using API which can do CRUD, so it could be difficult to change the setting to remove Update, as API is actually capable of “update”
Thats my understanding.
Also for me, losing the capability to UPDATE row, is not prefered…
I reported this internally if there is any reason why just Adds is not allowed.
I m watching you!
How this works… if the record in the CSV input file does not exist, it is created. If the record exists, it is updated. Since we do either an Add or an Update depending on whether the record already exists, we require both Add and Update to be enabled to perform CSV import.
We could probably change the behavior, but as Koichi said, it is not as simple as enabling CSV import when only Add is allowed. We would need to detect the presence of existing records and block the CSV Import.
Ok, I see the issue now. That does complicate things! Thanks for looking into it, @Aleksi.
I think I’ll set up the Import table to allow updates, but then lock each row for editing after a timestamp column is set. Then I can lock each row as it is added, effectively creating an ADD_ONLY table.