Hey Dave -

Thanks. I had been thinking along those lines as well since as Sergey said the nature of these keys doesn't really lend itself to straight translation to ints. But the number of tables and number of keys make this no small feat.

Actually later this afternoon I had a breakthrough in realizing how Strataframe actually handles UIDs and it is a lot easier than I thought, so I may not do this conversion, but simply use int identity keys in future stuff (unless I really do anticipate the kind of merging that made guids so useful in my VFP apps. May go to using newsequentialid() in those cases. )

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