I think we're losing to be synch in "upsizing". With upsize you're telling me about VFP's upsizing wizard I think. I do upsizing with my own handwritten (not so handwritten) code.
In previous example code change VFP table's GUID to be 16 bytes nocptrans and try:
Insert into FromVFPCustomer (pkid, customerID,company,contact)
select PkID,cust_id,company, contact
from OPENROWSET('VFPOLEDB',
'c:\Temp\';'';'',
'select * from "c:\Temp\test"')
Compare values with StringFromGUID2. They're same.
Cetin
Cetin
>But if vfp stores it as c(16) nocptrans it is still just a 16 char field and will not upsize to a Uniqueid.
>
>Remember, in upsizing the idea is to automate the creation of the SQL table, and to move all the data to the SQL server database. If I have a field with c(16) the only thing I can upsize it to is c(16), no? If I then try to change the data type of a char (16) to uniqueid in SQL server it won't translate.
>
>
>>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