skra (2/22/2008)
1.There are a lot of artricles on the SQL Server Central website about undocumented features of the SQL Server and which were found by readers quite useful.
True. And I always vote "awful" if I see an article that pushes undocumented behaviour without warning the readers that the behaviour is undocumented, unsupported, and likely to change with the next version, the next service pack, or even when the weeather changes.
The fact that you and I have never seen the "new" trick for "ordered views" fail is no guarantee that it never will. Suppose a big company reads your article, implements this "trick" and then makes a million dollar loss because it happens not to work for them - will you take responsiblility?
If there is a way to solve the big problem You currently have and there is no known documented solution for it than You will probably use undocumented one, even for the price of the problem in the future release of the product. Maybe it is not a good practice but when You are by the wall, You do not care.
But in this case, there is a way to solve the problem. By realizing that the whole concept of an "ordered view" (I can't even write it without the quotation marks) is fundamentally wrong, and that the order of a query can only be imposed by the ORDER BY clause of the outermost query.
2.
You are right that any undocumented feature may change with the next version of the product but the same happens to some of documented features. They become "depreciated" and they will in all likelihood will not be available with the one of future releases (this will happen with extended stored procedure).
This is unavoidable , regardless of, that if You use documented or uncodumented feature (with that difference that undocumented ones may change with the new Service Pack).
When a documented feature changes, you get advance warning. The feature is marked as deprecated but still supported for one, two or even three versions. After that, the feature is in some cases still around for one or two more versions in a compatibility setting. And the change is widely documented, so that any self-respecting DBA will know about it, and can prepare to replace code relying on that feature somewhere during the several years that the feature will still be around as a deprecated feature.
If the next service pack changes behaviour of views using your "trick", there wil be no advance warning, no grace periode, no nothing. Just application errors, angry users, and a need to update your resume.
3.
Moreover, if You had an application using such feature which was changed and You have an option to change a code of it and than prepare an update of binary files for customers and the second option to use a dirty trick and simply change the definition of the view, which one would You choose Yourself, considering implementation, testing and publishing time and costs ?
It's unlikely that I would ever have such an application, except possibly by inheritance.
And in such a case, I'd definitely push to fix the real problem instead of replacing a kludge with another kludge. It might take a bit more time now, but it'll save lots of time in the long run.
If a manager would presure me to go for a quick fix, I'd ask him why there's never time to do it good but always time to do it over. And then I'd remind him that he can pick two out of "good, cheap, fast" - but if "good" isn't in, then neither am I.