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