Sync Local Changes with AppSheet Changes on E...

[Buglouse]

Sync Local Changes with AppSheet Changes on Excel

I have Excel hosted on DropBox, my app is pulling/pushing to this file. Is there a method by which I can sync these local changes back to the hosted file, that has been changed by the app, keeping as many changes from both version as possible without conflicts?

Do I need to use a different data source/rethink my implementation?

I would focus on migrating to SQL (which would help me sync from multiple access), but now with the new pricing, I’m strongly deterred.

[pravse]

The problem with Excel is conflicts. The whole file is edited and saved. This has always been a problem.

Within AppSheet, we solve the problem by serializing all changes to the Excel file — i.e. even if two people sync changes to the same sheet at the same time, AppSheet ensures that only one happens at a time. But if you make changes via the app and also directly to a copy of the spreadsheet on your local file system, there is nothing that can coordinate the changes.

So if you use Excel on Dropbox, then you need to commit to modifying it only via the app, or treat the app as read-only.

If you use Google Sheets, you’ll get the behavior you want — because it is designed to support concurrent edits by different people.

[Buglouse]

Yeah, I really wanted to get away from Microsoft and Excel. Having extended Excel with VBA, is not scale-able.

Going to make the migration to SQL (yay). Trying to go over with sales the pricing. I’ve been hearing of 5000? If it costs 5k to use AppSheet with SQL. I’m going to have to use a different platform I’ll be using SQL as my data source regardless.

[pravse]

What sort of scale do you have? Have you considered using Google Sheets?

[Buglouse]

I don’t trust the longevity of google projects (ie. Google+), GSheets is here now but until when? I want the functionality, reliance, usability, everything with SQL. I’ve been meaning to migrate my data into a database and was so excited when I began my relationship with AppSheet that SQL integration was available and within my operating budget. My scale is not so much the question (although every decision is dictated by this consideration) but the data reliability and accessibility. I need to modify rows from an office workflow while operators are in the field accessing and editing the data as well. This is not possible with Excel (office overwrites all new data). It is possible (and preferable to use) with SQL. It is very disappointing to me and my team that migrating our data to SQL will result in another “AppSheet” discovery and development phase. We are not willing to cover the price for AppSheet SQL integration. Even if I were providing development for 30 apps with 150 users (was the annual projection), the cost would be too large of a margin. I’m trying provide development for businesses who do not yet utilize digital-technology, the operating budget for IT is not cohesive to AppSheet’s Pricing. It is confusing to me to deduce the market your focus is on especially from your original model. Again, it is disappointing to loose the great resource AppSheet is and the active community is supports. I hope to find a solution that fits my needs and expectations as well as AppSheet has.

[pravse]

@Buglouse, I understand. My background is actually as a database systems professor and then worked for almost a decade at Microsoft in the SQLServer team. So I do understand why one would choose a SQL database and sympathize with those reasons.

A few comments though:

*) if you have your data in a database, then all updates are always going to go thru some app. So if you’re going to build apps for all users anyway, then you might achieve the same outcomes building those apps on AppSheet and the backend doesn’t matter as much. Another way of saying this is — if your followed the same patter but left your data in Excel, all updates would be executed by AppSheet and things would not get overwritten.

*) Google Sheets is really an excellent product and very successful. I doubt it is getting discontinued. You could always export and move at that time if so.

*) Yes, we decided to move database integration to the business subscription. Why? Because the primary use cases for a database involve developers (business users are unlikely to every figure out SQL queries) and usually it is because of scale or transaction requirements or integration with some other database-centric system or … these are typically business scenarios of higher value. The case of a simple low-value low-scale app that must put its data in a SQL database is not very common.

*) In the prior pricing model, with 150 users and the PRO plan (that used to have SQL integration), you’d have been paying $1,500 * 12 = $18,000. You’re in identical territory with a business subscription today. So I don’t quite get why the pricing is driving your decision.

I don’t want to do a hard sell, but I hate it when a customer is happy with the platform but leaves perhaps without fully exploring the options. If you like, you could send some details of what you’re planning to sales@appsheet.com (please do cc me at praveen@appsheet.com).

[Buglouse]

I want the option to use SQL; I’m moving away from Excel (I’m native to GNU/Linux and SQL before this adventure and thought I would give Excel/MS as shot, found AppSheet which factored in the convincing.) AppSheet is/was designed to be my User Interface and VBA in Excel (now SQL with some CRM platform) to

handle Office tasks that require complex scripting for CRM/Inventory/Management. Using App and Excel doesn’t model as updates are always conflicting. I would like an incremental pricing plan so that I may continue to use AppSheet through this business management development process. If I had the sales, I may be looking at the pricing through a different perspective, but now all I see is a barrier to entry. Trying to start-up my rocket-ship.

[pravse]

Best to send details to sales@appsheet.com like I suggested. Thanks