For now wouldn't it be a workaround to remove sort on click the header but make it a transform function ?
A workaround to what? That's a key question here. What are you trying to accomplish?
Let's zero in on that so that if the right tool is available, we can talk about how to use that right tool. If the right tool is not available, no problem, what should that right tool look like? ...so you can effortlessly accomplish what you need to do.
Whatever we do, it is important to do that without muddying the rest of the system. Let me give you an example of what I mean.
Suppose, for some reason, you want to see a table with records sorted by some field. Just why it is you want to see a table sorted by the value of some field drives what makes sense to do.
A Transform template isn't the way to provide a sorted view, because transform templates either change something in a table or they create new tables. There's no such thing as a "sorted" table in Manifold or, for that matter, in any big DBMS.
To see records in a table in sorted order, use an ORDER BY query to get a results table, a report, in sorted order. That's not transforming a table. Wouldn't it be better, if a new tool is required, to put it somewhere more related to what it does?
In fact, such a tool is already available: I have a table of 9 million records for LiDAR data, and I want to see records where Intensity is greater than 89. Cool. I have three, very fast ways to do that within the table window, if that is the user interface preferred:
1. Just right click on a value of 89 and choose the preset >= filter choice. Done. That applies the filter to those 50K records already fetched. It's a fast way to get a feel for what is going on based on a representative sample.
2. Having done that, in View - Filter uncheck Filter Fetched Records Only, so the filter now goes through all 9 million records and provides the first 50K records it finds. That's an even more exhaustive way. When you uncheck Filter Fetched Records Only you're running filters against the entire data set: run several filters on various records and you might reduce your results down to just a handful of records out of 9 million.
3. Use SQL with a single click: In View - Filter, click on Filter using Query. Right away, that pops open the command window loaded with the equivalent query to 2) above. Note that this method in no way limits what it produces: if it turns out that 8 million of those 9 million records are picked out by the query, they'll all be available for any further use. It's only if you look at them in a window manually that you get 50K presented as a sample, but the universe of all 9 million records will be your source for any queries you create based on that "Filter using Query" query.
Now, what you do with the above depends on why you want to see a sorted table.
Suppose you want to see a sorted table so you can manually scan the table to find duplicates. No way are you going to be able to do that reliably with 50,000 records, not by eye. Suppose you could dial that number up or down, so you could fetch, say 100,000 records. That doesn't change anything, since it is still too much to do anything with by eye.
The right way to find duplicates in any table larger than a trivially small table is using SQL. You're going to make errors when trying to find duplicates by spending days scanning page after page on the monitor, dozens of pages a minute, but SQL isn't ever going to make a mistake.
Look, the current table window is a hack, put there to cater to expectations based on experience with very small data. It's still highly useful for that, but sometimes it promotes really bad habits and amateurish workflow (like scanning by eye for duplicates) that work against developing more professional skills that scale better. I still love it.
I had as big a role as anybody in the design of the table window tools in 8 and I love the thing. But I'm honest enough to admit that for certain things it seduces you into amateurish workflow that is much worse than learning a better way to do it.
8 has facilities to save you from the worst of that, like the Duplicates functions in the select toolbar. Such tools, which automate a better, SQL, way of doing things I believe are a better way to go in 9, than to expand a tool which is already an unrealistic GUI (the table Window) into something even more unrealistic.
Let's get away from the unrealistic belief that the best way to accomplish stuff in tables is to manually scan screen after screen by eye in a table window. That's like manually rowing across the Atlantic instead of taking a First Class flight. Let's consider two sets of numbers:
50,000 records - At 56 records per table window that's 893 screens. If each screen is 40 cm high, that's 357 meters worth of small text records if each screen were laid end to end. I don't believe anybody who says they accurately can scan, by eye, a roll of paper 357 meters long that is covered with tiny text and do that without making mistakes. That's just daft.
Scan a few screens at the beginning or the end, sure. Scan a screen here or there somewhere in the "middle", sure. But all 357 meters? No way. And 50,000 records is just the "sample" size the table window provides.
8,000,000 records - That's equivalent to a roll of paper 57 kilometers long. If you want to use a roll of paper 57 kilometers long covered with tiny numbers as your interface to learning anything at all about LiDAR data you're nuts.
The only sensible way of handling such tasks is through automated means, which is why people invented SQL.
Can Manifold provide ever more useful tools to make it easier to automate various things using SQL? Sure. The only question is what are the things you do, which could be automated. For example, if you're in the habit of finding duplicates, why not a "Duplicates" and "All Duplicates but First" choices along with a bunch of others in the View - Filters menu?