实践证明，为超大的DBF表提速，终极杀手锏便是字符串哈希。
具体算法，网上到处都可找到C源码。
众所周知，VFP是32位的，整型变量和字段，也都是32位的。
而好的哈希算法，需用到64位的大整型数。
之前有大侠提示过：在vfp2c32.fll中，提供了一系列64位整型数计算相关函数，现在问题是：
不仅仅需要在中间过程进行64位大整数的计算，还需要将64位整型数结果保存到DBF表中，并且要能高效检索。
这个储存与检索的问题有些麻烦：
似乎，只能以字符串或二进制字符串的类型来保存，索引与检索（Index和IndexSeek）效率会不会受到较大影响？
毕竟，32位整型的效率，在VFP当中，那是相当高的！

尺有所短，寸有所长
与其讨论性能上的瓶颈，不如直接把问题抛出来，大家一起寻求解决办法

[此贴子已经被作者于2022-5-5 08:24编辑过]

举个例子。设：
N1 = 3772834016  &&即16进制0xE0E0 E0E0
N2 = 2880154539  &&即16进制0xABAB ABAB
在VFP中，是无法计算N1+N2=？，因结果超出了32位整型数的最大值范围，导致结果数值溢出。
又或者：
N1 = 247256450130144  &&即16进制0xE0E0 E0E0 E0E0
N2 = 188753807911851  &&即16进制0xABAB ABAB ABAB
在VFP中，我们也无法计算N1-N2=？，因N1和N2都超出了32位整型数的范围。

那么，可以想到的解决方案，似乎是：
将64位整型数，按32位分割成高低两段，分别进行计算，然后再小心处理一下高低两段之间的进位与借位即可。
大整数用16进制来表示与储存会比较方便一些，起码比较直观（0xE0E0 E0E0 E0E0远比247256450130144优雅漂亮好多，不是吗？）
然而，在DBF表当中，则不应将0xE0E0 E0E0 E0E0储存为ASCII字符串“0000E0E0E0E0E0E0”，因为那意味着将原本64位（8字节）的数据，储存为16字节的字符串，长度扩大了一倍，计算开销也扩大了一倍，无形之中，也就失去了“字符串哈希”的意义了。
也就是说，0xE0E0 E0E0 E0E0应当保存为可变长二进制型(Q，Varbinary)：0h0000E0E0E0E0E0E0，仍为64位（8字节）。

现在问题来了。如何高效在地在两种类型之间相互转换：
3772834016  ←→ 0hE0E0E0E0
2880154539  ←→ 0hABABABAB

还有，可变长二进制型(Q，Varbinary)在索引、检索与一些函数方面的限制，会不会对我们进行64位整型数模拟计算时，造成不必要的麻烦？
我觉得，这可能也是需特别注意的问题。

还用vfp2c32函数呗，Int642Str，Str2Int64

没有一种语言是万能的（否则其它语言就被淘汰了）。如果经常涉及到超大数值，VFP显然不是好的选择；C系列好像也不如Python吧。

有点儿“跑偏”了。
暂且先抛开64位整型数吧，也先抛开VFP2C32。
在VFP当中，有没有现成的函数，或者简便高效的方式，能够直接进行这样的相互转换：

I, Integer  ←→  可变长二进制型(Varbinary)
3772834016  ←→  0hE0E0E0E0

这样一来，当我计算得到3772834016（即0xE0E0E0E0），便能够直接地将其实际数值，正确地转换为二进制原文0hE0E0E0E0，然后储存到dbf表中；
当我计算得到0xE0E0 E0E0 E0E0 E0E0，也能够直接地将其实际数值，正确地转换为二进制原文0hE0E0E0E0E0E0E0E0，然后储存到dbf表中。
反之，当我从dbf表中取出二进制原文0hE0E0E0E0，便能够直接地将其转换为实际数值0xE0E0E0E0，然后进行数值计算；
计算完毕，再将最终结果正确地转换为二进制原文，然后储存到dbf表中。

如此，问题的第一步，便简化为，在VFP当中，能否方便地直接进行这种相互转换：
I(Integer)  ←→  二进制原文(Varbinary)

类似转换，其实不需外求vfp2c32之类第三方函数，在VFP语言内部便能够办到。
讲真，我对VFP语言不太熟，我能想到的一种“啰哩啰嗦”、很不优雅的方法是：

I = 3772834016
C = TRANSFORM(I, "@0")
C = "0h"+SUBSTR(C,3)
B = EVALUATE(C)
? B

正所谓“精益求精”吧，直觉告诉我，理论上VFP应该有更简洁、更优雅的转换方法的，恳请大佬们指教！

C库API有输入输出函数

这样行吗
I = 3772834016
?CHRTRAN(TRANSFORM(I, "@0"), "x", "h")

感谢sdta指教！这个跟7#区别不大。

另，二进制原文（或可变长二进制）0hE0E0E0E0与普通字符串"0hE0E0E0E0"，是完全不同的两种字符串。