Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Updating SQL data on a web host

Status
Not open for further replies.

johnhodgson

Programmer
Nov 23, 2000
27
0
0
GB
I need to 'fix' some data in an SQL database on a web host.

Making a remote view of the table opens some of the fields as memo fields with every other character being a non-displayable character [I think they are chr(0)]. I've tried turning on and off the character translation in the ODBC data source, with no effect.

Can anyone point out the elementary mistake I'm making?

Thanks
John Hodgson
 
John,

It sound like the server is storing the data as Unicode (or some other double-byte character set).

VFP does not have a native way of dealing with that. You could easily write a little conversion routine using the STRCONV() function to strip out the leading characters. However, I don't think there is any way of restoring those characters when you want to write the data back to the server.

The only other solution I can think is to acquire a third-party Unicode control; this would read the data into an edit box, let you edit it, and then write it back. But that seems like a bit of overkill for what should be a simple requirement.

Mike


Mike Lewis
Edinburgh, Scotland
 
John,

One other idea, off the top of my head ....

You could perhaps create a temporary table on the server, using 8-bit ASCII characters rather than Unicode. Then, copy the data from the original table to the temp table; access the temp table in your remote view; update the temp table; and copy it back to the original table.

For that to work, the data would have to be in an 8-bit character set. Assuming you are working in English, that won't be a problem.

Mike


Mike Lewis
Edinburgh, Scotland
 
Mike

Very belatedly, thanks. We solved the problem by converting the SQL table, as there was absolutely no need for it to be unicoded.

John
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top