Hi Kyle,

O.K. so I'm nearly 3 years replying to this post but none the less......

I agree that tune tables is a very necessary and useful tool in order to improve query performance.

Where it does fail in my opinion, much to my disappointment is that the tune table data is stored within the actual class rather than elsewhere. This causes a major tune table flaw for classes that are mapped over 2 or more namespaces as the tuning needs for one namespace could and often is completely different for the tuning needs of the other namespace.

Are you aware of any ways to get around this problem please?


It would seem that your REGINUS database expansion size has been set to 1000, this can be checked via the SMP using System->Configuration->Local Databases and clicking on the relevant database link.

I would hazard a guess that your cachetemp database has an expansion size of 0 which is the system default hence why it is growing at a lesser rate.

If you run ^%GSIZE in the relevant namespaces then you will be able to see which globals are taking up so much space.

There is of course the possibility that you had work objects/globals being created that have since been deleted and therefore you could have a lot of empty space in your database. This can be resolved using both Database Compact and Truncate. These options can be found in the SMP under System->Databases and clicking on the relevant database link.


I'm  not too sure about accessing different namespaces via SQL but you can use a variety of %ResultSet objects but personally I prefer using an SQL cursor with SQL open, fetch to iterate through the object.

My 'personal' reasons for preferring SQL cursors is that they are extremely fast to develop but more importantly if you add/remove indices in the target class then the class that uses the cursor will use the best available indices without requiring re-compilation unlike at least some of the %ResultSet methods.