>Hi Charles,
>
>Sorry for my previous message. I'm very interested in your routine of converting these keys to SQL Server GUID fields. Can you please post it or e-mail me?
>
>Thanks in advance.

This was actually the easy part.
cguid is a guid(16)

cguid36=left(cguid,8)+"-"+substr(cguid(9,4)+"-"+RIGHT(cguid,4)+"-0000-000000000000"

That will map out to a guid(36) which is a text string that Sql will see as a Uniqueid.

I first massage my VFP data with a prg, replacing empty dates with nulls and fixing the guid(16)s then use a program called FullConvert ( about $250 for the enterprise version ) which does a very nice job of mapping to SQL structures and moving the data.

I find the VFPOLEDB driver maddening to work with SSIS etc and this is just easier.


>
>>I'm considering doing a major conversion in data structures on an app I am porting from VFP/DBF to .NET/SQL. The .NET framework I use (Strataframe) loves int keys. UIDs just involve a little more tweaking. The app I am converted currently uses pseudo-guids
>>( guid(16) ala the old Rick Strahl algorithm) for every primary and foreign key - and there are a *lot* of them. VFP/VFE loves them. My current VFP-DBF -> SQL conversion routines convert these guid(16)s to guid(36) and then to UID
>>
>>current keys look like this :
>>

>>8298499C6C924F97
>>3EBF95B8F4FE4681
>>591BB961D6194082
>>

>>
>>I am math impaired, but I believe the guid(16) is a valid Hex number. (actually, at one point I had DTS reading them as binary(16) and they converted to UIDs but in some revision of OLEDBVFP that stopped working )
>>
>>Ideally I would need an algorithm that would convert that to an int16 (is that what identity fields are in sql?) If it could be reduced to something smaller, just to give me more wiggle room in setting the seed for future numbers, great.
>>
>>It would be a one-time conversion, just need to make sure all the pk-fk relations remain intact.
>>
>>thoughts?