I had a chance today (19 Mar 2010) to take a look inside a .tps file. This is the file created by Clarion's "TopSpeed" (or "Top Speed" ?) application / database. I wanted to know what sort of data structure they were creating. It's odd to say the least. In my discussion below I use the terms "block" and "frame" interchangeably. If you have taken a class in general data structures, at a university, you may have an introductory feeling for these, but essentially a file handling program will set aside a set of contiguous bytes immediately for future use by a file storage program. As the file grows, more "blocks" get appended as needed, or discarded when unneeded.
Firstly, the tps file is a Random-Access file. I'm not sure if the size of each block is universal, but the one I reviewed uses 512-byte blocks. The first block is evidently a kind of file header. At least in the file I reviewed it doesn't appear to have much "information" stored directly in it. Mostly some form of padding. Its possible however, that it declares how many tables will follow, and in which blocks each table begins. There appears to be some minimal information here, and perhaps that's what it represents.
As with all (I think all) Random-Access files, each block will have a "link" line which specifies the forward and backward block pointers, or some indication that the block is "unlinked" (i.e. has no links). Sometimes block structures will declare the number of directly linked frames (i.e. the next four directly link) or have a longer jump to some arbitrary block appended. Not sure yet exactly how tps handles all this.
Each Clarion tps frame appears to begin with a Hex 20 (space), or possibly they space-fill the first field, which appears to be a kind of frame number. The blocks appear to all be even numbers, so the first datablock is block 2, the next is block 4, then block 6 and so on. There appear to be six space-filled fields in the link line. I'm not yet sure what they each mean, although the first one is quite long and perhaps is just a kind of CRC-type hash to ensure that the block hasn't been altered.
The trailing "empty" ends of each block are padded out with Hex B0. If you didn't pad the trailing bytes, your frames would push together and you couldn't do direct jumps properly to the first byte of a particular requested block. In other words, the padding allows each frame to start exactly on a half-K boundary point (i.e 512, 1024, 1536, 2048, etc).
You can open .tps files in Notepad. You will be able to see, a bit of data that "means" something, but part or most of it will be invisible (because it's non-printable hex) or gibberish. This is because some of the data fields in the tps format are numeric or date fields, which use compression. The hex codes they generate for each byte can represent non-printable ASCII characters. So notepad doesn't show anything for those bytes. They don't display as ASCII numeric strings. Tps files do not use tab as a delimiter, nor comma, nor bar, and yet some of the fields are variable-length.
I wrote my own data file parsing utility tool in PHP which displays a line of text, a line of hex, and the byte-count positions, to help me decipher this.
The TPS data file, uses Hex 08 as a kind of separator between "lines" of data, i.e records, which is of course not needed after the last record in a table, which is apparently terminated with a space (Hex 20).
I've determined much more about the structure of the TPS data file, but this information is for sale not for free. So contact me if you're interested, wjhonson@aol.com