SQLStatement states that "statements may not return result sets larger than 1x1."
Based on what I see in the Android source code, the critical line seems to be line 55 of SQLiteDirectCursorDriver. I may have a fighting chance if I violate some rules and use an SQLiteQuery directly. I could become desperate enough for the ugly hack, but it means 10,000 database structures are out of date. Nathan On Feb 23, 10:33 am, Kostya Vasilyev <[email protected]> wrote: > Can't speak for the effects - I've never ran into this myself. > > One idea: > > SQLiteStatement has methods to bind actual parameter types, including > bindDouble: > > http://developer.android.com/reference/android/database/sqlite/SQLite..., > double) > > And here is an idea for an ugly hack, just for completeness: > > If you don't need all the double-type precision there is, you could > pre-multiply your floating point numbers by some power of ten, turning > them into integers (I don't mean 32-bit integers, just that there is no > fractional part, or a fractional part you can discard). Then binding > them as strings should work - provided this is acceptable to your data > logic. > > -- Kostya > > 23.02.2011 21:23, Nathan пишет: > > > > > > > > > > > I'm seeing this in my log. > > > 02-23 09:50:09.293: WARN/Database(27780): Reached MAX size for > > compiled-sql statement cache for database /mnt/sdcard/bcnav/data/ > > *****.**; i.e., NO space for this sql statement in cache: > > "***************************" > > Please change your sql statements to use '?' for bindargs, instead of > > using actual values > > > I would absolute *love* to do parameterized queries, but there is the > > following problem: > > > IT WON'T WORK.It is absolutely useless for floating point > > inequalities, as I've posted here last year. You can do the same query > > with parameters and string concatenation and get a different answer. > > The answer with the parameterized query is just plain wrong, because > > the FLOAT column is cast to a string. This is likely not even > > considered a bug because the documentation states 'The values will be > > bound as Strings.' > > > Given this situation, what do I do? > > > Can I prevent this error? Given that under these conditions, a > > statement cache is useless anyway, can I stop it from adding to that > > cache? > > > And what adverse affects should I expect with this warning? It hasn't > > appeared to crash so far, but it probably isn't good. If I do have any > > sql statements that are eligible for caching, there probably won't be > > any room left. > > > Nathan > > -- > Kostya Vasilyev --http://kmansoft.wordpress.com -- 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
