Re: Unexpected results from forcing the ChangeTo

Can you more simply set the RETURN value of your Stored Procedure to
@@IDENTITY?

-----Original Message-----
From: Alan R. Parker [mailto:[email protected]]
Sent: 27 02 2003 16:32
To: [email protected]
Subject: [OLEDB_DEV] Unexpected results from forcing the ChangeTo


I've got a worker function which having completed an insert does the
following:

//to get the id of the field, requery the database with the @@IDENTITY
string

_variant_t vNull;
vNull.vt = VT_ERROR;
vNull.scode = DISP_E_PARAMNOTFOUND;

// having done the insert...

_bstr_t bstrQuery("SELECT @@IDENTITY");

//create a recordset to hold the queried data which is the identity
adoRS->Open(_variant_t(bstrQuery), vNull ,
   ADODB::adOpenStatic, ADODB::adLockBatchOptimistic,
ADODB::adCmdText );

_variant_t vID;
vID = adoRS->GetCollect(L"");

//vID.ChangeType(VT_I4); // hangs here
*lPrimaryKey = vID.lVal;

//close the recordset
adoRS->Close();


Now given the schema of some of my database tables, it seems I don't always
expect, in this worker, to get a valid vID.lVal back - if I actually call
ChangeTo on the vID.lVal, against SQLServer2000SP3, the com+ server hangs,
the database has outstanding locks, and eventually the (scripting) clients
time out, or if I shutdown the calling object, the system sorts itself out.

Now these #imported calls are inside a try catch which I'd have expected to
fire, seems it doesn't .. if I put a simple local catch all around the
vID.ChangeType(VT_I4) then I get to continue without hanging.

Now I appreciate that ChangeType might be failing based on the actual table
that the generic function as called to act against, but I'm loathe to
remove the explicit coersion...

Arp

You can read messages from the OLEDB_DEV archive, unsubscribe from
OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.