Evan,
To SQL server it doesn't matter. 36,38 char formats are equally recognizable as a uniqueidentifier (and 16 bytes formats too, in SQL server it's 16 bytes). IOW to SQL server these are same uniqueidentifier values:

'36DE74B0-5920-4F58-8060-BDA8E7BE37B7'
'{36DE74B0-5920-4F58-8060-BDA8E7BE37B7}'
0xB074DE362059584F8060BDA8E7BE37B7

PS: If VFP is storing it as c(16) then must have nocptrans to prevent code page translation.
Cetin

>Hi Charles,
>
>Do your char(36) values have beginning and ending braces? If not, try making them char(38) then adding the braces to your strings with REPLACE ALL and see if that makes a difference...it did for me once before.
>
>Just a crazy, off the cuff idea, but HTH.
>
>>Kardeşim
>>
>>Perhaps I don't understand your answer. I have a vfp table I want to convert to a sql server table. My char(36) field looks exactly like what I see in a uniqueid field, but in using either DTS through the vfpoledb driver or going from VFP to SQL with the upsizer I do not seem to have the option of telling SQL I want this information to be seen as a uniqueid.
>>
>>I have been able to use this field information with SPT and it does indeed match values in sql. My remote views generate these keys on the front end and they are accepted by sql with no problem.
>>
>>I am just lazy and looking for an easy way to convert existing VFP tables to SQL tables and not have to manually change the char(36) fields in sql to uniqueid.
>>
>>Sağol
>>
>>>
>>>Charles,
>>>I didn't use upsizing but with SPT and alike SQL server recognizes 36,38 bytes versions, 16 bytes version and strconv(x,15) version.
>>>Cetin