>There is a very specific reason why we use a decimaled number as a PK. It has to do with merging multiple databases from different sources while avoiding PK conflicts. Integers and Identity fields do allow for multi-database table mergers. etc. The decimal portion of the number represents the database id, while the INT portion is a simple counter. Thus as long as the database id of each system is unique we can merge databases easily. Works VERY well in VFP.
>
>Regardless of the field being a PK or not, when using remote views where the field is defined as B(8,3) all seems OK, however when using SQL pass-through the numbers are being rounded...
>
>Any ideas?
Not really. I think your numbers are somehow being treated as "real numbers, low precision", that is, 4-byte reals.
Other options for the PK include GUIDs, and combining a few characters for the location (for instance,
bintoc(location, 2) + bintoc(serialnumber)), but I realize it might be difficult to change the PK system if it is already in place for a long time.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
