PROBLEMA
A partire dal SQL 2005 un eventuale ORDER BY presente all'interno di una vista NON viene eseguito, ovvero facendo una select sulla vista i dati non vengono restituiti ordinati secondo quanto specificato nella definizione della vista stessa.
Al contrario, SQL 2000 rispettava l'ORDER BY all'interno delle viste..

ANALISI
In effetti il comportamento di SQL 2005 e superiori è assolutamente corretto: per definizione una vista è un sottoinsieme dei dati presenti nel database all'interno del quale l'ordinamento non è garantito (tant'è che lo standard SQL non ammette l'utilizzo di ORDER BY in una CREATE VIEW). D'altra parte, una vista è paragonabile (dal punto di vista dell'utilizzatore finale) ad una tabella e, nella creazione di una tabella, non è possibile specificare alcun ORDER BY.
Ciò nonostante, SQL Server non solo ammette la clausola ORDER BY nelle viste ma, nella versione SQL 2000, la rispettava anche ovvero una eventuale SELECT su una vista "ORDINATA" ritornava i dati ORDINATI.

Questo comportamento è stato modificato a partire da SQL 2005 (aggiungerei giustamente): l'ORDER BY all'interno delle viste viene ignorato e i dati vengono restituiti così come sono.
Da un punto di vista logico SQL 2005 si comporta più che correttamente: purtroppo però, nel passato, moltissimi programmi si sono affidati all'ORDER BY all'interno delle viste e, passando a SQL 2005 o superiori, hanno manifestato degli ovvi problemi. 

La ovvia risposta a questo problema potrebbe essere "chiama chi ti ha fornito il software illustrando il problema", ma il più delle volte quello che viene richiesto è "rimettilo come prima, dato che prima funzionava": d'altra parte spesso gli applicativi che manifestano questo problema sono o molto vecchi (e quindi vengono migrati solo per mantenere uno storico) oppure sviluppati in casa ma, come sempre, il team di sviluppo è sempre incasinato in altre attività, senza considerare la fatica di ridistribuire la nuova versione agli utenti.

SQL 2008 R2
Consci di questa situazione Microsoft ha rilasciato una serie di patch per "convincere" SQL Server 2005 e superiori a comportarsi come SQL 200: l'articolo di riferimento è il KB926292 dove si spiega che è necessario passare applicare una apposita patch. Peccato che l'articolo faccia riferimento a SQL 2005 e SQL 2008 ma non a SQL 2008 R2: questo lascia intuire che, di default, SQL 2008 R2 (ovvero l'ultimissima versione) abbia già al suo interno la patch indicata.

Purtroppo però una veloce prova dimosta esattamente il contrario: di default SQL 2008 R2 non rispetta la clausola ORDER BY nelle viste.

Se però si legge più attentamente l'articolo, nella parte "After you apply this hotfix" :

KB926292

 (P.S. Riporto l'immagine perchè mi è capitato più di una volta che un articolo venga modificato aggiungendo/togliendo pezzi interessanti).

Ovvero, per rimettere le cose come erano prima non basta mettere il DB in modalità 80 (quella di SQL 2000) ma è necessario attivare il Trace Flag 168.. Peccato però che l'articolo parli di SQL Server 2005! Stando a quanto riportato, sembrerebbe che il flag sia valido solo su SQL 2005 mentre SQL 2008 e SQL 2008 R2 necessitano semplicemente del DB in modo 80 (tutto sommato sarebbe stato logico: se ho il DB in modalità compatibile con SQL 2000, allora le viste devono comportarsi come in SQL 2000!).

La risposta ovvia è che anche su SQL 2008 R2 (e, immagino, anche su SQL 2008 che però non ho provato) per attivare la compatibilità con 2000 è necessario attivare il trace flag 168.

Per attivare il flag ad ogni startup del DB è necessario specificare l'opzione -T168 negli startup parameters del servizio, tramite l'apposita console SQL Server Service Management (ricordarsi di separare questa opzione dalle altre con un ; )

Una alternativa potrebbe anche essere l'utilizzo del comando DBCC TraceOn(168) ad ogni startup di SQL (magari con uno script dentro il SQL Agent).