Hi Rick,

It is possible, an example is below.
However, I'd like to know more details about the following quotes:

> I'm having a heck of a time getting consistent behavior depending on how parameters are passed.
>

>In most cases this is fine, but there aer a few instances when I need to explicitly override the parameter types to get the data into the database correctly. I also prefer the approach where users can add parameters explicitly using an AddParameter function which allows for all the type info.
>

Could you describe specific scenarios (preferably with code)? What exactly is inconsistent? Why the way CursorAdapter passes parameters doesn't work for you?

The code:

CLOSE DATABASES ALL 
CLEAR
SET MULTILOCKS ON

LOCAL oConn as ADODB.Connection, oRS as ADODB.Recordset, oCom as ADODB.Command

oConn=CREATEOBJECT("ADODB.Connection")
oConn.Open("Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Data Source=(local)")

oCom = CREATEOBJECT("Adodb.Command")
oCom.ActiveConnection = oConn
oCom.CommandText="select * from Northwind..Orders where customerID = ?"
oCom.Parameters.Refresh()
oCom.Parameters(0).Value="ALFKI"

oRS = oCom.Execute()

LOCAL oCA as CursorAdapter

oCA=CREATEOBJECT("CursorAdapter")
oCA.DataSourceType="ADO"

?oCA.CursorFill(,,,oRs)
LIST
USE

Thanks,
Aleksey.


>Hi all,
>
>Another question about the CursorAdapter. My main goal here is for building a data adapater that simulates what SQL Passthrough does with ADO. I have everything hooked up and it works reasonably well, but I'm having a heck of a time getting consistent behavior depending on how parameters are passed.
>
>Is it possible to use the CursorAdapter to essentially provide only a Recordset to DBF conversion without letting the CA have anything to do in manipulating the SQL?
>
>WHat I'm finding is that I can't add parameters to an ADO Command object directly and have the CA process the command. The CA always tries to step in and override the parameter behavior by doing VFP parameter parsing on it.
>
>In most cases this is fine, but there aer a few instances when I need to explicitly override the parameter types to get the data into the database correctly. I also prefer the approach where users can add parameters explicitly using an AddParameter function which allows for all the type info.
>
>So ideally I want to set up my own command object get it all set up and even create the Recordset on my own and then tell the CA to read the data from already retrieved Recordset. Or at least tell the CA to not do anything to the Command object at all but just call Execute to generate the RS.
>
>Is this possible?
>
>

>*** Set up or reuse adoConn object.
>IF !THIS.Connect()
>   this.nSqlResult = -1
>   RETURN -1
>ENDIF
>
>LOCAL oCommand as ADODB.Command
>oCommand = CREATEOBJECT("AdoDb.Command")
>oCommand.ActiveConnection=this.oadoconn
>oCommand.CommandType= 1 &&adCmdText
>*!*   IF LOWER(lcSql) = "exec"
>*!*        oCommand.CommandType=4 && adCmdStoredProc
>*!*   ENDIF
>
>oCommand.CommandText = lcSQL
>
>*** Parse the parameters from oParameters collection
>*** OR parse VFP style parameters
>THIS.AssignCommandParameters(oCommand)
>
>LOCAL oRS as Adodb.Recordset
>oRS = CREATEOBJECT("adodb.RecordSet")
>oRS.ActiveConnection = this.oadoconn
>oRS.CursorType= 0  && adOpenForwardOnly
>
>*** THIS RETURNS WHAT I NEED - but I can't tell
>*** the CA to load it
>* oRS = oCommand.Execute()
>*****
>
>ca.DataSource = oRS  && Now assign
>
>LOCAL llError, llResult
>llResult = ca.CursorFill(.F., .F., 0, oCommand)
>
>*** Gives error result about missing parameters etc.
>
>*** Parsed command string:
>*** Select  * from wws_invoice where invdate < ?
>*** Error: Sql Parameter is missing
>*** Works with ADO - oCommand.Parameters.Count = 1
>