Perhaps TPS files can theoretically support a key that large, but it’s a terrible idea to actually do that in the real world. 
Why, are you forgetting that SSD & NVMe drives exists now and they are not that much slower than memory chips?
SSD vs HDD - Comparing Speed, Lifespan, Reliability (tekie.com)
The NVMe’s I have are so quick, that it gives TPS’s files and other ISAM db file technology a new lease of life. I havent even bothered getting the In Memory Driver out to improve performance, NVMe are that quick!
Spin Disks today still have, at best, a seek time of 4ms, SSD’s et al typically 0.1ms and the data throughput on SSD et al are at least twice as fast out the box compared to spin disks.
Spin disk only bring reliability.
I understand what you’re getting at. However, keys that large tend to represent rather specific sort situations. I typically use keys with fewer components, as it will narrow the selection of records that need to be sorted by the additional values. It’s just a matter of whether you do that sorting when you first add the key (making ADDs a bit slower), or whether you do the sort later (making your reads a bit slower). You pick your poison.
Remember that TPS files aren’t as stable as SQL. They tend to corrupt, and don’t work well in heavy multi-user situations (especially if a record add requires that many keys be updated). Also, OpLocks et al. need to be adjusted away from the Windows default.
If this is a single-user program, or primarily read-only, then this caveat probably doesn’t apply.
Hi Mike
In our case we were getting the ERROR 78 with SQL.
When debugging why we were getting the error, and that was fun, we found that POSITION was returning long strings. All our KEYS are < 1024 characters in size, so in SQL’s case it seems the problem is not just down to cutting back KEY size.
We decided to increase the size of all variables that were to store POSITION throughout the classes and templates. We didn’t run testing on each scenario but decided that the hammer fix was better than keep trying to debug the issues caused by error 78.
Thankfully since that day we haven’t had many more error 78’s and none of the ones we have had were down to position.
Mark
1 Like
Thats the key, horses for course.
Thats debatable. They both suffer the same risks of disc corruption, if not running a RAID config. Out the box the TPS is not designed for heavy multi user situations, where as SQL is, but thats not to say a class that incorporates the features of sql couldnt be made. TPS hasnt had as many design hours spent on it, unlike SQL servers, so its like comparing Apples with Oranges, but the new drives still give TPS and other ISAM db files a new lease of life, which is perhaps why free versions of various SQL servers have been made available, but these SQL servers need alot more resource to work, so in a limited resource environment, TPS & other ISAM db files still out perform SQL server with perhaps the exception of SQL lite, because they can work in a limited resource environment.
Edit
One other point, MS SQL server is an attack vector Server-side attacks, C&C in public clouds and other MDR cases we observed | Securelist
Trying getting your TPS files to hack back! 
1 Like
I think its not the one Primary File’s Key Position Size, but that the Browse uses Position(View) that includes position info for the Secondary Joined Files. I pasted info in the below topic. Also 1 post lower down a quick idea to throw the LEN(Position(View)) in the Browse to see it.