Charles,

I think I'd do this into a set of staging tables to start, using a native SQL server int identity as the PK. Then you can use INSERT - SELECT with JOINs on the original c(16) keys into the ultimate destination tables carrying forward only the new int PKs as the FKs.

If you have less than 4 billion rows in these tables int32 keys will be better then going to int64.

>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?