title: SQL and sqlite3 both return correct results for `count(*)`. SQLite for Android always returns 1. How can this be? Why isn't it a bug?
body: <p>Please consider this program segment:</p>
  
  <pre><code>Cursor cursor = mDatabase.query(TABLE_NAME, mColumns, null, null,null, null, null);
  int nRows = cursor.getCount();
  </code></pre>
  
  <p>Note from <code>Log</code> output below that this returns the correct number of rows to <code>nRows</code>--86000.</p>
  
  <p>Here is what any SQL-savvy developer would expect to also return 86000 to <code>x</code>:</p>
  
  <pre><code>Cursor c2 = mDatabase.rawQuery("select count(*) from " + TABLE_NAME, null);
  int x = c2.getCount();
  </code></pre>
  
  <p>Here's why they would expect that--sqlite3.exe produces that result:</p>
  
  <pre><code>sqlite&gt; select count(*) from wordlist;
  86000
  </code></pre>
  
  <p>However, the result returned to <code>x</code> by Android SQLite is <strong><em>1</em></strong>.</p>
  
  <p>Here's the <code>Log</code> statement that is at the bottom of the code above:</p>
  
  <pre><code>Log.w("`````dbDump","rows: " + nRows + " or is it " + x + " rows?");
  </code></pre>
  
  <p>Here's its output:</p>
  
  <pre><code>W/`````dbDump: rows: 86000 or is it 1 rows?
  </code></pre>
  
  <p>The answer is that the database has 86000 rows, not 1.</p>
  
  <p>My question is simple (and is stated in the Title):</p>
  
  <p>Why would anyone trying (even if loosely) to simulate SQL design a commonly-used function such as <code>count(*)</code> to always return the same value? </p>
  
  <p>If you choose to downvote me, go ahead, but answer that question, please. It seems like a bug because no one would expect a constant result to always be returned by any function.</p>
  
  <p>Gripes that resemble questions:</p>
  
  <p>You'd expect 1 to always be returned if this really is documented somewhere and you found it. In that case, where? (URL, please?)</p>
  
  <p>Is there really a use for <code>count(*)</code> to always return 1? (I suppose an answer could be that to remove it or make it work right would require a major rewrite.)</p>
  
  <p>If you do not think that these are legitimate questions, then you didn't spend too long a time trying to find out what you were doing wrong, which, as it turns out, was simply using SQL knowledge and <code>rawQuery</code>.</p>