What is happening is that the vfpoledb provider is using Code Page 1252 where as the Char datatype in .NET is using UniCode. so when we declare a variable to be of type Char, we create a two-byte value, by default, all characters in the Unicode character set require two bytes.

Solution:
The .NET framework supports the Byte value type. This type contains a value between 0 and 255 that exactly matches the range of the Code Page 1252 character set. Instead of converting the string to a char, convert it to a byte array. Then Encode the byte array with CodePage 1252 before converting it to a String. The sample below produces the same "dot" that appears in VFP.

Byte[] bytLrt = new byte[1];
bytLrt[0]=(byte)149;
System.Text.Encoding CodePage1252 = System.Text.Encoding.GetEncoding(1252);
String cString = CodePage1252.GetString(bytLrt);

>Cathi,
>Thanks for the reply. I think, though, that my main problem stems from the fact that the chr(149) doesn't originate in my .NET app. It comes from a table in VFP, through the vfpoledb provider. It is apparently not the same thing when it arrives in my c# app. Any thoughts?
>thanks,
>jfh
>
>>I just ran this sample code and it returned 149. Try this and see what you get:
>>
>>

>>String cString;
>>Char mychar;
>>mychar=(char)149;
>>cString = mychar.ToString() + "ABC";
>>int lnChar = (int)Char.Parse(cString.Substring( 0, 1 ));
>>