Hi Don,

>Yes, and not to mention that you need to be using the database concept in order to use views. I have been unable to get myself to use databases because of all the ways in which it ties my hands when I wish to accomplish things which once were simple and now become almost impossible... like rebuilding indexes, modifying structures, adding blank records to files containing primary keys, etc ... the list goes on.

You can use an empty database exclusively for the purpose of using views, but on the other hand, it seems you're making your life miserable by forcing yourself to use surogate keys. Maybe its best to forget this whole concept and rever to intelligent keys.

However the shortcommings you list are managable. Sure, they are a bit more difficult and less straigthforeward than when using free tables, but these problems can be avoided. Most frameworks offer you methods to do the work for you. If you don't have/want a commercial framework, you should be writing your own set of classes, tools and userinterfaces.

Walter,


>It seems to me that after all is said and done, if the user absolutely MUST be able to have the expense data sorted by category description, it may be just as well to let the category description be the primary key for the file of expense categories and only allow editing of that description in some sort of separate system process where all of the categories are changed in the expenses file also. A lot of processing but seldom needed.
>
>>
>>
>>You're right, this is not easier with surrogate keys. It is not reccomended to add such indexes to tables as you're asking for troubles. The most easy way out is by using sql-views and order them on any particular column or index the view.
>>However, views have the disadvantage that they:
>>
>>1. Don't display the most recent data (it's really a snapshot).
>>2. Take considerable amounts of time to load.
>>