Re: FMTONLY problems

Bob wrote:
"Bob Barrows [MVP]" <reb01501@xxxxxxxxxxxxxxx> wrote in message
news:u9moIvjoHHA.3736@xxxxxxxxxxxxxxxxxxxxxxx
Bob wrote:
"Bob Barrows [MVP]" <reb01501@xxxxxxxxxxxxxxx> wrote in message
news:OQAeAwYoHHA.4516@xxxxxxxxxxxxxxxxxxxxxxx

You failed to provide the ADO code that is causing this behavior.


OleCheck(Cmd.QueryInterface(ADOCommandConstruction,
ADOCommandConstructionObj));

OleCheck(ADOCommandConstructionObj.OLEDBCommand.QueryInterface(ICommand,
ICommandObj));

// there was a whole lot more code here to get parameter types,
names and direction etc

So do you get the FMTonly problem if you execute this Command without
bothering to get paameter types, etc?


No. Without the QueryInterface lines in the example I don't get the
FMTONLY errors.

So that seems to be your answer isn't it? What is the point of getting the
parameter types, etc., when you already know them?

It doesn't seem to be too optimal even then though.


All right, what is not optimal?

I suspect the fmtonly is being caused by your choice to use "SELECT 0" to
return the procedure result rather than "RETURN 0". Using a return parameter
would eliminate the necessity to marshal a cursor. Create and append a
parameter with direction adParamReturnValue (it has to be the first
parameter appended to the Parameters collection), execute the command using
the adExecuteNoRecords execution option, and read the value of the return
parameter rather than using a recordset.



--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"


.