Check the value being sent to @merrordesc. Remember, SQL Server doesn't really know the difference between a field and a variable. You define your parameter @merrordesc as char(254). Should the length of @merrordesc be greater than 254 or contain invalid characters, you might get the problem you are experiencing.

Set a watch on the VFP variable SQLERROR and make sure it is always empty. If this doesn't turn anything up try returning an int instead of a char from your stored procedure and handle the message on the front end.

The other possiblity is that some other output text is being generated (like an SQL Error) during your stored procedure. Allowing for SQL output can often play havoc with ODBC. Try putting SET NOCOUNT ON at the top of your SP. This disables any SQL output.

Hope this helps.

Eric Shaneson
Cutting Edge Consulting

>Thanks for your reply Eric. First at all, I am using SqlPassThrough. The store procedure that I am executing is quite simple. It just delete a table from SQL server. The strange things here is this error occurs 10% of the times that I execute this store. The other 90% works perfectly. I'll explain in a short table the procedure. I have a this form with 3 store procedure. The first one is the one that have this problem. This one delete the table in SQL. The second one Insert Rows and the third just tell the SQL server that I finish. This procedure is to create an Invoice. We had to do in this strange way to avoid blocks in SQL Server. So, next invoice I want to create, I will delete first. Well, sometimes this store procedure generate an error. I don't use CR or LF character. I call the store procedure in the following way:
>SqlNroError = 0
>SqlError = ''
>SqlExec(C_Handle,"{CALL MANBDeudaXFac (?@SqlNroError,?@SqlError)}")
>
>Both parameters are output. Sometimes SqlNroError returns 1 and the error of the ODBC. The Other times return 0 and the description is Transaction OK.
>Here is the structure of the table in SQL Server if you are interesting
>
>Id Int
>Quantity Int
>IdType Int
>Amount Numeric(15,2)
>
>Also I'll paste down the code of the store procedure:
>
>CREATE PROCEDURE MANBDeudaXfac (@merror tinyint output, @merrordesc char(254) output)
>AS
>delete MANLIBA..MANDeudaXfac where spid = @@spid
>
>if @@error <> 0
> begin
> select @merror = 1, @merrordesc = 'Error de sistema. Llamar a Tecnología'
> return
> end
>select @merror = 0, @merrordesc = 'Transaction OK'
>GO
>
>
>
>
>
>>The error is probably on the back end, since the message you are getting is fairly common SQL error.
>>
>>Text is a variable-length ASCII text field, generally equivalent to a VFP Memo field. Char is a fixed-length character field, generally equivalent to a VFP Character field. ODBC will normally typecast Text to Memo and Char to Character.
>>
>>If this error message is occuring intermittently I would look at the data itself first when the error occurs. Are you using Memo fields here? Are there characters (like CR/LF or TAB) in the SQL UPDATE/INSERT statement that would be suspect in a character field?
>>
>>Also, you didn't indicate if you are using SQLPassThrough or remote views. With remote views you can explicitly typecast. Sometimes ODBC will do some funny things when creating the view and incorrectly cast something as something else. There's some info on the Knowledge Base about this stuff.
>>
>>If this doesn't help at all you might want to post some more specifics.
>>
>>Eric Shaneson
>>Cutting Edge Consulting
>>
>>>Hi everybody: I am working with VFP 5.0 and SQL 6.5. I have a simply query store that I execute many times in the same day. I Always use 2 parameters to handle the errors in case I had one. This name are SqlNumberError and SqlError. The first one is integer and the second is Char. Sometimes the ODBC returns me the following error:
>>>
>>>"[Microsoft][ODBC SQL Server Driver][SQL Server]Implicit conversion from datatype 'text' to 'char' is not allowed.  Use the CONVERT function to run this query."
>>>
>>>I don't know why I receive this message, because I don't use Text or Char. Which is the difference? Does anyone know where is the error? Is in the Front End or in the Back End?
>>>Thanks in Advance!
>>>
>>>Roberto Comolli        e-Mail : RComolli@disco.com.ar
>>>Disco SA
>>>Larrea 847
>>>1117-Buenos Aires
>>>Argentina