Firebird Embedded + AUTOINC

[Perlsau]

Zitat von himitsu:

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.

Zitat von himitsu:

... 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

Zitat von p80286:

Äh Entschuldigung *hust*

Hier hast du ein Fishermen's extra stark

Zitat von p80286:

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 ...".