Hello Neil!

Replying to a message of Neil Heller to Jasen Betts:

 NH> I use "Watcom SQL" version 4 - that's the last version Watcom made 
 NH> before they sold the SQL package to Sybase (now it's known as SQL 
 NH> Anywhere).  I had a programmer friend at Sybase, but he got the axe 
 NH> (along with a large number of others in a personnel cutback) so now
 NH> I'm  out in the cold.

 NH> The following command works perfectly in the Watcom interactive 
 NH> environment:

 NH> select count (*) from  where 

 NH> The count command became part of the SQL standard in SQL-92.  
 NH> Unfortunately, I have not been able to find a corresponding command in 
 NH> ODBC.  If I were to use the count command in an SQLExecDirect
 NH> statement,  I don't have a clue as to how I could retrieve any sort
 NH> of return value.

SQLGetData?  Same as any select?

 NH> ================== example =============================

 NH>  HENV  benv;
 NH>  HDBC  bdbc;
 NH>  HSTMT bstmt;

 NH>  wsprintf(char_str,     // wsprintf is a Windoze work-alike
 NH>  "SELECT count (*) FROM Names WHERE %s LIKE '%c%s%c' OR %s LIKE / 
 NH> '%c%s%c' ORDER BY %s",     "Name", "grp",
"Name", '%', target, '%',
 NH> "Sortstr", '%', target,     '%', "Sortstr");

 NH>  char_to_uchar  if (p_open_database(&benv, &bdbc, &bstmt)) {
 NH>     retcode = SQLExecDirect(bstmt, uchar_str, SQL_NTS);

SQLINTEGER count;
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_DATA)
{
  SQLINTEGER cb;
  SQLGetData(bstmt, &count, 0, &cb);
}

(This is just from reading the msdn for the last 5 minutes after a google
search on "odbc api" - I've never dealt with odbc before in my
life.)

 NH> =========================================================

 NH> retcode = integer indicating whether or not the call was successful,
 NH> bstmt = statement handle, SQL_NTS = ODBC macro indicating the string
 NH> being sent is null  terminated.

 NH> note:  "LIKE" searches for embedded substrings.

 NH> The value returned by the command doesn't get placed in any sort of 
 NH> table - I think.  Another consideration is whether doing a query such

No - all selects create new (temporary) tables from which you then
generally read all the data.

 NH> as  the one above will really result in time savings over
 NH> constructing a  linked list on the heap for about 200 entries.

YES!  I use count() soooo much, and as long as it's counting either
everything or something where there's an index, it's way faster.  Way, way,
way faster.  Even without using the index it's still faster than reading
everything into memory in a linked list and then counting that yourself.

 NH> Theoretically, the database can handle over a billion records.  It
 NH> might  be interesting to note the time difference in that situation.

 JB>> or you could pass any object that has access to the query result and
 JB>> methods similar to those of a linked list.

 NH> That would result in calling SQL queries outside of the database
 NH> class:   something to which I am (at this point) loathe to do.

 JB>> I've seen badly written database applications die horribly when the
 JB>> number of users climbed, but those guys weren't even using odbc 
 JB>> AFAIK. if they were they could have goone with a big SQL  server
 JB>> whaty they were doing instead was relying on shared DBF files...

 NH> Ack... x-base.  Actually there IS an ODBC driver for x-base 
 NH> applications.  However, I don't think that would help a great deal.

Darin
C_PLUSPLUS moderator
dmcbride{at}tower.to.org

---