Glad to hear you got at least a little speed out of the transactions. On making sure your objects are in sync, I can understand the reasoning behind this. What I tend to do is drop database modifications in a thread and also updates my objects at the end of that thread and then trigger a refresh on the UI when the thread is finished.
Are you updating a ton of data each time, or just a few rows here and there? In the response, you said you were reading every row of every table, is there a reason you are doing this? The right SQL statement should prevent you from having to do this. If you are using a ListView, a CursorAdapter helps for dealing with delayed reading automatically. I also write web applications, so if you need a hand with SQL or how to speed up querys, don't hesitate to ask in this thread. I deal with databases that have millions of entries that are join across a ton of tables (and cross database), so I may be able to help speed up your SQL statements. Steven Studio LFP http://www.studio-lfp.com On Friday, October 14, 2011 3:54:37 PM UTC-5, John Goche wrote: > > > On Thu, Oct 13, 2011 at 1:47 AM, Studio LFP <studi...@gmail.com> wrote: > >> If you aren't, try using transactions: >> >> dbHandle.beginTransaction(); >> lReturn = dbHandle.insert( sTable, null, cvEntry ); // Update and delete >> here also >> dbHandle.setTransactionSuccessful(); >> dbHandle.endTransaction(); >> >> If you do multiple inserts/updates/deletes where you target specific rows >> for a reason you can't include them all in one query, add more statements >> between the beginTransaction and the setTransactionSuccessful. >> > > > Thanks Steven, I have implemented transactions and it runs about twice as > fast but still have to wait a somewhat > smaller fraction of a second. > > As to the connection it's only opened once and shared across intents. The > queries are based on primary keys > so I do not see the need to have separate indices. > > I think what is slowing things down could be the fact that I am reading > every single row of every single table just to > be on the safe side although things could be done more efficiently but at > the risk of complicating the code and > introducing bugs in the code. As to implementing the database calls in a > separate thread, the reason I didn't do it is > that the calling activity needs to display the data from the popped > activity retrieving it from the database to make sure it's > data remains consistent with the database. But it's true, I could store the > data in the database in a separate thread and only > read it when the application starts, and just write to it asynchronously. > This would really make my app faster. Or I could display a > progress bar in between operations. I just want to ensure my objects are > always in sync with my database so I > have a soreAndRetrieve() data method to make sure this happens at the > expense of speed, so maybe it's my > own problem. > > Thank you for all your replies, > > Regards, > > John Goche > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
