Best way to convert from google sheets to sql server asap

[Rurrea]

Having extreme syncing issues, so it seems i need to finally convert to an sql server. What is my best option. I am unfamiliar with sql server, but need to convert asap.

[WillowMobileSys]

You should perform some analysis first.  It most likely is not data size that is causing the slow Syncs.  This would mean that moving to a database will not solve the problem.

How large is your data?

Have you looked at the performance analyzer to see where your app might be spending most of its time? 

Is there data in the app that can be purged or archived?

Assuming, that analysis does determine you need to move to a database, the other challenge is if you have your sheet ready to migrate.  If you have any formulas or queries in the sheet you need to determine how you are going to handle that processing.  

Beyond that, if your sheet is "clean", meaning it has only column headers and data, then migrating your data can be a simple as exporting to a file and then importing that into the database. 

Some database import functions will also read the column header info and generate table columns for you (you will need to adjust data types afterwards).  In some cases you may need to create the table with columns and then import the data from the file.

[Rurrea]

The degree of parallelism is high. 

My Order Table: 27K rows, 13 columns

Order Detail Table: 37K rows. 7 columns

Product Table: 42K rows, 11 columns

Other references in Order Table:

Customer Payments, deliveries, warranties, Furniture, and a few others

My Order table: has several virtual columns that may be the main issue, but when removed still extremely slow.

How can i resolve this? App is becoming unusable at this point. 

[WillowMobileSys]

Yes, those are tables on the larger size and a database will help.   It will take a few days to get it established and there are additional substantial costs associated with activating database connections.  Be sure to research it.

For a quick fix, the app likely does not need 27000 Orders loaded for daily use.  I would look at using Security Filters to bring in maybe only the last 60-90 days of Orders.  Then filter the other tables to only those that references a filtered Order.

It would be worthwhile to check if anything can be filtered out of the Product table as well.

NOTE: Use Security Filters - not Slices.  Slices still require ALL data to be down-loaded to the device.

Then create a second app solely for looking at the history.  This app will not need all of the calculations, etc.  It is just a read only app so even with all of the data loaded it will be slightly faster.  (I am not sure if we can use  User Settings to set a Date Range for filtering of the history.  It would be worth trying.)

Then, in the future, to get more sophisticated, in this History app, create an action to set an Order to be "reactivated".  A flag that indicates that this history record should appear in the main app.  And of course adjust the Security Filter to allow in any Order with the flag set.  These Orders are pulled into the main app and then can have additional edits applied to them.

You can also do the reverse of "reactivation".  Once an Order becomes fully Complete - Delivered, Paid, any follow-ups, etc - then mark for archival.  Security Filter then eliminates these archived records, further reducing the app data size.

With your app design using Security Filters and archival, you can likely get by for quite a while before needing a database.  Maybe indefinitely depending on how it grows in features.