There a some differences between ODBC drivers when it comes to updating Text fields. I think the later release is actually less useful, but it still works fine.

What I have found is that the remote view must be of a SQL table. I generally create SQL Server views of all tables and then create the remote view against this view. Text fields won't update this way. The remote view must be against base table in SQL Server. (Although it will work against a view with an earlier version of the ODBC driver).

The conversion problem you are getting may be caused by the field mapping. Check the properties form from the view designer and make sure your text field is mapped to a memo field. It should do this by default.

Also, the default value of Text fields in SQL Server should be NULL. It is important to create a default value for Text fields and to set it to NULL otherwise you might find yourself retrieving garbage.

Other than the above, I found working with Text fields the same as working with memo fields in DBF's and there were no other 'tricks' to perform.

One thing I wouldn't do is have varchar(255) in the database. set your varchars to 254. these will come back as character fields to VFP but 255 will come back as a memo. The ODBC driver may be failing when it takes the cursor memo field and converts the data to a varchar for updating in the database.



>I don't think this is a new thread per se, so... We have a situation where we are trying to use a Text field as a memo field in an SQL (6.5) table. We have remote views setup and get a ...conversion from text to varchar... error whenever we enter a significant amount of data and then issue the update. You made it sound like it might be tricky to do, but possible. Is this an ODBC issue? Is there something we can do programatically to handle it? Thanks!
>
>Regards, Renoir
>
>>>Is there an advantage to using Varchar over Text in SQL*Server? Let's say I have a situation where the expected limits are under 4000 bytes, so that I might be willing to force a truncation in an Edit region, if there were benefits. Is there a (performance or feature-based) reason to avoid Text? Given my VFP heritage, my inclination is to think of Text as like Memo, and use it for anything long.
>>>
>>>TIA,
>>>
>>>-- Randy
>>
>>Varchar holds only up to 255 chars. If you need more than that you should use text. Text fields are not nearly as easy to use within Transact-SQL as memo fields, but they look just like regular memo fields in VFP. There can be problems with updating text fields when the VFP remote view is based on a SQL Server view. Remote views based on tables work fine.
>>
>>Text fields are slower in SQL that varchars, but that is to be expected. Like memo fields, you can't do LIKE operations.