The 16 digits hexadecimal value represent 8 bytes integer - bigint in MS SQL Server. It's easy to convert them like this

SELECT CAST(0x8298499C6C924F97 AS bigint)

The IDENTITY column in SQL Server can be of any numeric type. It's not limited to one data type like in VFP.
However your existing keys do not lend themself for IDENTITY column because their values kind of random and IDENTITY by nature is sequential. IOW, existing max value of the key could be too close to max value supported by bigint.



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