(Actually, what I would be tempted to do is to essentially journal each update done to the master DB on the server. Ie, for each insert, update, or delete of the master copy I'd essentially capture the associated SQL query (though perhaps in some compressed form). Timestamp each such captured query, and keep them in a sequential file. When the phone "checks in", have it pass a timestamp corresponding to the last sync operation that it did, and forward to the phone all of the query statements that have been recorded since that time. Apply the received queries, then update the phone's "last synced" timestamp with the timestamp from the last new update applied.)
(Occasionally truncate the front off the server's journal, and if a phone ever asks for something prior to the first entry then send the entire DB.) On Feb 22, 9:47 am, feeder1803 <[email protected]> wrote: > Hi! I am starting to work with Android and SQLite and I have some > doubts regarding the database update. I have a SQLite database in my > application with a supermarket catalog. As the catalog doesn't change > a lot, I would like to update it from a webserver that I own. The > problem is that I am not really sure of how to do it with the maximum > performance. > > I don't want to download the whole database because it would be too > big, I've thought of placing an xml file in the server with the > registers that have changed and the new values to download it and > parse it on the phone generating SQL queries to update, delete or > insert. > > Another approach woul be updating the app but I think this would be > slower as it would download the whole database. > > Any ideas? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
