Thanks for the callout @dbaum , I’ll update the wording. Each user is entitled to 10 databases and each of those databases can be a maximum of 2,500 rows.
-
There are no security filters restrictions today. Since we own the backend, we just do a complete sync under the hood. So it handles all security filters.
-
This applies to apps that use ASDB only. This will switch back to opt-in based quick sync if there are other data sources.
1 Like
Perhaps there should be a new payment plan specified for ADSB meaning pay as you grow. I believe it’s not hard to run a script that checks usage and can assess or predict usage based on usage history.
2 Likes
I don’t think it suits me at all, it’s too expensive
1 Like
I have a problem during data migration.
Conventionally, when using Google Sheets as a data source, set the “ID” column to KEY and generate a unique value for Initial Value using the UNIQUEID function.
The KEY value set for this “ID” column is not consistent with the AppSheet Database RowID.
When migrating from Google Sheets to AppSheet Database, the KEY value of the “ID” column cannot be inherited or replaced with RowID. Therefore, I cannot replace the data source of an app that sets “Ref” as the KEY value for the “ID” column with the AppSheet Database.
Is it correct to assume that data migration from Google Sheets is impossible as a usage of AppSheet Database?
It seems the confusion is who is the “user” this refers to? App Creators or licensed app users?
Below are the terms that AppSheet has decided on within the Table settings so we should make sure we use these same terms in all communications and documentation
4 Likes
Hi @AppliSuite , how are you migrating your app? If you copy the entire app and choose AppSheet database, it should still save your preferred “ID” column as the table key, and references should still work like before in the app. The “ID” column will still have the same initial value function UNIQUEID().
The key column can be changed inside the app editor at any time but this means you will not be able to set references from the AppSheet database UI, making it more similar to Sheets. More details here: https://support.google.com/appsheet/answer/10106672?hl=en&sjid=4515579216879630996-NA#system-generated-key Copying the entire app would be the preferred method.
2 Likes
Im trying it out and it seems very useful. Just a few questions. Is there a way to change currency of price from USD, to NZD for example. Also i dont see a way to reference other tables with a type of formula like SUM all prices less than 0.
I’ve been quite excited about the release of this product, but currently these limits are too limiting.
In it’s current format I feel like this will work well for people just starting out, or small apps that are not used much. It won’t work for me with the larger apps that I have made. I have one table with 25,000 rows. I’m on an AppSheet core plan, so couldn’t even fit this in a database. 20 tables is not enough for my larger apps either. I feel like the row vs column limit is a bit unbalanced as well. My 25,000 row table has 12 proper columns, plus some spares, with very little data in each field.
If I increased to an Enterprise plan I will probably take the opportunity to just use a MySQL instance. Other than the interface I don’t see much advantage over an SQL database of whatever flavour.
It would be interesting to be able to split/partition an app across multiple databases. This may make it more attracive than an SQL database.
I’ll keep an eye on how this develops.
11 Likes
Thanks for your replying, @ShirleyN !
By copying the app as you said, the data migration from Google Sheets to AppSheet Database was successful. Some “Ref” type columns set in the app also work fine on the app.
“Ref” type columns on the AppSheet Database UI are related by RowID, so this will not work. I understood that the “Ref” type column in the AppSheet Database UI after data migration does not work as a Reference and is almost like a “Text” type column.
After the data migration, I understood it would be fine to just use the AppSheet Database as a backend data source just like Google Sheets.
Thank you very much.
I have two question.
Q1.
Is there a way to see the status of AppSheet database sharing across the organization?
For example, I would like to know if one AES user is sharing his AppSheet database with 100 other people.
(even though the contracted license is only 20 Lic! 
)
Q2.
Is the ability to manipulate the AppSheet database directly from the AppSheet Editor on the roadmap? There has always been a challenge for citizen developers to use spreadsheets and the AppSheet Editor differently. I remember that one of the missions of the AppSheet database was to address that issue. Is the development of that functionality still ongoing?
Thanks.
1 Like
I have to agree with the general consensus…although I love a number of AppSheet’s database features, with these level of column/row limitations, I cannot even begin to consider migrating.
Rather disappointed. I was really hoping for an increase for core users when compared to the public preview, as was kind of insinuated…really wanted to make the switch.
Hopefully this is reconsidered, because again, love the platform.
8 Likes
Hi @takuya_miyai ,
For Q1, unfortunately there is no consolidated view for seeing share status of a database right now. The best way would be to go to the database’s audit logs, and filter by “Add/replace database sharing” events to get a sense of how many people have access to the database.
For Q2, this is still an ongoing effort. It is quite complex and there are many edge cases to consider so we want to be thoughtful about it. We’ve also been looking at feedback from users to try and understand which part exactly is the challenge.
2 Likes
Thank you @ShirleyN
@ wrote:> > For Q1, unfortunately there is no consolidated view for seeing share status of a database right now.
I understand that there is no functionality at this stage.
What I am wondering is, if the AppSheet database is shared, does that count as a licensed user and will it be billed?
GWS users routinely share and use Sheets and Slides. if ASDB is shared in the same way, will it result in unintended billing?
For Q2, this is still an ongoing effort. It is quite complex and there are many edge cases to consider so we want to be thoughtful about it. We’ve also been looking at feedback from users to try and understand which part exactly is the challenge.
I understand that functionalization is still being planned.
Not specific to ASDB, but where does the AppSheet team feel feedback should be collected?
For example, I feel that collecting feedback in this Announcement thread is not a very effective way to collect feedback.
In fact, I personally think it would be desirable to collect feedback along with requests in the Feature idea.
1 Like
Please dont COPY the app from an existing app in production to this new appsheet database. It will just break your entire app in production.
- I copied the app and started testing with below setting. It just copied only couple of tables to new database (20 tables) rest of tables remained in existing production google sheet itself (did not copy to new googlesheet/database).
- I kept testing the newly copied app by making bunch of changes to test the performance and advantages over google sheet. This suddenly stopped my production app. The issue was shown below. An empty column was auto added with random ID in all the tables of production database. (I didn’t re-check database connections before making changes. Appsheet default behaviour is to copy database to new spreadsheet)
-
Managed to delete all those unwanted columns and fixed the error in production app.
-
Performance wise I did not see any difference between both apps using google sheet and database. Sync speed and update speed remains same.
7 Likes
My team and I just spent several months migrating from Google Sheets based apps to ASDB and designed a bunch of AppScript projects to keep our data to less than 10k rows per table only to find that the ASDB feature was GA-ed with the limits implemented essentially crippling our existing apps as they all exceed the limits and rendering our efforts pointless.
3 Likes
@ShirleyN There should be another limit in terms of max number of characters per cell (field) of ASDB.
It looks like 49826 as per my own testing. which is slightly less than Google Sheet.
From my point of view, Google Appsheet team seems to be a habitual liers, sorry to say again, but this is true.
I sincerely hope a return of the original management team of Appsheet to listen to our voices rightly.
Anyway, Google is promoting ASDB is scalable and bring the benefit to scale the app data sources, comparing with the given available circumstances. However, it is actually false statement, i have to admit. Google Sheet is more scalable, stable, and easy to handle…It is better to stop to announce the false statement to the user , as it simply cause the nagative impact, i.e. the mis-understandings, dissapointment, mis-guidance, lies, etc etc. Not sure where Google Management team wish to bring us. Unless the Google could not get the full support from the active users, the growth of the platform is going to be capped… This should be learned in the school, isnt it?
We observes the management failure of AppSheet team (sorry to say) after the aquisition by Google in 2020. Not much benefit and values were added to the users, but Google enjoys its own play and games (most of them is not in line with the expecation of users), while the benefit of the users leaves behind. Im sorry to say but this is true as it looks like the Google AppSheet team seems to be habitual liers as it keep pushing the false statement all the time…
3 Likes
What Google does say, but the reality is totally opposite kinda things: -
-
This community place is monitored by Google staffs all the time to support you. ----- No . this place is left to the volunteer supporter to get active. No Google skillfull stuff for support (we know it is not avaiable) supervising.
-
Give us your feedback for new features. ---- We know the Feature request category never being reviewed and prioritized. Google internal interst is prioritized, which result in the new features which is not broadly used by the community.
-
We hear the support desk and services are enhaunced, but we all know the personnels in support desk is with less skills and knowleges about the appsheet. They should be educated not to support the end users, burt focusing on closing the ticket.
-
This is no-code platform, but keep pushing the users to use the coding tools such as Apigee etc. This is the departure of the original concept where the AppSheet was born. Google is bringing the platform to coding/low coding platform, while forgetting teh appsheet is no-code plaform.
-
Apparently, Google is ruling out the non-GWS users from appsheet. AppSheet was eco-system before, i.e the compartible with any other plaform and services, but currently only friendly with GWS users.
It it late at night my time. I stop over, although there are tons of other negative observations.
All in all, this is management failure. Time will tell.
9 Likes
Could you please tell me the rules for generating Row IDs for the AppSheet database?
The reason for my question is that I would like to know the extent to which Row IDs can guarantee uniqueness.
As far as we can see, they are generated randomly using alphanumeric symbols, and we believe that it is practically impossible for identical keys to be generated.
However, I would like to know if it is not merely random, but if uniqueness is guaranteed within the same database.
Related AppSheet help point
2 Likes
I have a large database of about 70000 rows, I didn’t expect such a limit 
1 Like