|
|
Posted by Herb Caudill on 03/22/06 05:03
>> You didn't read this thread very well. A view or a function does NOT
return any data <<
Whatever. That seems to me a very abtruse point to make in response to a
practical question.
Maybe the problem here is that I want SQL to be something more than it
is. As an object-oriented programmer, I expect to be able to encapsulate
logic at the lowest possible level. In this situation, "logic" includes
sorting logic. The conclusion on this thread is that there's no way to
do that - that in a chain of nested views/functions, the sorting logic
has to take place at the very last minute - which means that it has to
be reproduced and maintained in many different places. That's
unsatisfactory.
A similar problem having to do with encapsulation - perhaps a topic for
another thread - is that I can't write a generic function to perform
consistent operations against multiple tables. For example: Most of my
applications have a number of tables that are all subject to the same
versioning and approval logic, which is a little complex. A table-valued
function like this would be very useful to me:
Create Function GetApprovedItems(TableName as varchar(50)) returns Table
Of course, I can't do that because it would require building and
executing a command that contains the name of the table, and you can't
have an EXEC statement in a function. I could do something like this in
a stored procedure, but I can
Navigation:
[Reply to this message]
|