Und das Sortieren geht natürlich auch ohne VIEW problemlos ...
Natürlicht geht das auch ohne View problemlos, aber es ist – meiner Ansicht und Erfahrung nach – einfacher, wenn man alle Spalten bereits mit Spaltennahmen vorliegen hat, statt sie in der Sortiermethode nochmal alle einzeln angeben zu müssen. Du kannst auf diese Weise auch Views in ein anderes View einbauen, so daß du auch auf Felder von Sub-Sub-Tabellen zugreifen kannst.
... bzw. es hätte auch mit einem VIEW nicht funktioniert, wenn man, so wie ich, in der
Query-Komponente nochmal eine andere Sortierung drüber jagt.
Genau das mache ich doch auch in der oben auszugsweise dargestellten Sortier-Methode, die z.B. aufgerufen wird, wenn der Anwender auf eine Titelspalte klickt. Im View selbst wird bei mir gar keine Sortierung vorgenommen, das erledigt immer die Sortiermethode, die je nach ausgewählter Spalte das Property IndexFieldNames setzt. Natürlich kannst du jetzt einfach behaupten, das würde nicht funktionieren; bei mir jedenfalls funktioniert das genau so: Ich "jage" im
Query, das die View-Datenmenge beherbergt, sozusagen auch eine andere Sortierung drüber
Will sagen: Ich verstehe deinen Einwand nicht wirklich
Hier hast du ein Fishermen's extra stark
der Aufwand für einen/eine (?) View ist natürlich nicht kleiner als für eine "normale"
query. Aber (wenn man's richtig macht) dann ist sie getestet und getestet und getestet ... und mit einem einfachen
select ... from V_OpenInvoices
bekommt man was man will, da braucht's nicht bei jedem Aufruf wieder diese ToDate(to_char(to_date....)) frickelei, oder was auch immer an Effekten zu beachten ist.
Nicht einfacher und dann doch einfacher
Genau so ist es:
"... und mit einem einfachen select ... from V_OpenInvoices
bekommt man was man will, da braucht's nicht bei jedem Aufruf wieder diese ToDate(to_char(to_date....)) frickelei ...". 