Re: Returning a single record: is adExecuteRecord a mistake in docs?

> So, my questions are:
> 1. Am I gaining enough by switching to a "Record" over a "Recordset" to
> warrant pursuing this route?

Yes it is. Gains of up to 15%. We use Singleton Selects.

> 2. Is adExecuteRecord a mistake in the docs?

No. Something else is wrong.

> If so, what is my best choice
> for opening a "Record" from a sql select statement? Could my Provider be
> limiting me?

No. Your basic mistake is you _CANNOT_ return a Record from a ADO Command
object, only a RecordSet object. That is the source of your "Type Mismatch"
error.
What you do is (alternative method)

recTemp.Open(connVantage, other parameters)

making sure that the connVantage connection is setup and recTemp's
connection IS NOT.
Note: This 2nd method also works for recordsets and is necessary if you wish
to get a recordset back from a command object with different CursorType's &
LockType's other than the defaults.

Allowing for the fact that I am working in VC++, I have (using 1 parameter
Command object - so temporary StoredProc with 1 parameter),

>>>>>>>>>>>>>>>>
m_pADOCmd->Parameters->Item[0L]->Value = Parsed.szInputString;
hr = m_pRecord->raw_Open(_variant_t((IDispatch *)m_pADOCmd),
vtMissing,
ADODB::adModeRead,
ADODB::adCreateNonCollection,
ADODB::adOpenExecuteCommand,
_bstr_t(),
_bstr_t());
>>>>>>>>>>>>>>>>

I also find that if there is no record an exeception is generated. In VB,
you might find that ERRs is set (I think that is right, my knowldege on VB
is hazy)

Stephen Howe


.