Firebird Embedded + AUTOINC

[Perlsau]

Zitat von himitsu:

Sortiert das eigentlich auch neue Datensätze?

Aber sicher doch. Wenn ich einen neuen Datensatz einfüge, steht der immer gleich an der richtigen Stelle, wenn in der Query-Komponente IndexFieldNames mit einem oder mehreren gültigen Feldnamen gesetzt ist. Das ist doch Sinn und Zweck dieses Propertys, z.B.:

FireDac: Mit IndexFieldNames erstellen Sie Ad-hoc-Sortierreihenfolgen.

Oder anders ausgedrückt: Bislang ist es mir noch niemals untergekommen, daß eine via IndexFieldNames sortierte Datenmenge nach dem Einfügen oder Ändern eines Datensatzes nicht mehr korrekt sortiert war, und zwar bei allen mir bekannten Datenbank-Komponenten (FireDac, FibPlus, IbDac, dbGo, Zeos usw.). Einzig mit der BDE hab ich keinerlei Erfahrung vorzuweisen, aber die sollte man ja sowieso nicht mehr einsetzen.

[himitsu]

Hatte bisher nur im Grid sortiert (was richtige Grids ja können) oder halt über das SELECT und die Sortierung vom Select wird ist nach dem Laden nicht mehr existent.
Neue Zeilen rutschten beim ORDER-BY da rein, wo der Cursor grade stand (Insert) oder ans Ende (Append).

[himitsu]

Soooo, ich glaub nun geht erstmal alles wieder.

Hätte nicht gedachte, daß für solche "Kleinigkeiten" so viel Zeit drauf geht.

Zuletzt gab es nur bei dem Query probleme, mit JOINs drin.
Anfangs ging es und dann plötzlich nicht mehr, obwohl ich mich nicht erinnern kann da was Schlimmes geändert zu haben.

Waren beim Insert Fehler wie Folgendes, obwohl das Feld nachweislich gefüllt war.
[FireDAC][Phys][FB]validation error for column "COINS_SERIES", value "*** null ***"
Oder beim Löschen "Feld xxxx nicht gefunden", was auch klar war, denn das kam auch aus einem JOIN.

Viel rumprobiert und ich glaub FireDAC ignoriert die ProviderFlags, mit welchen es (vor)zuletzt versuchte.
Nun ja, aus "SELECT *, xxx, yyy" statt "SELECT xxx, yyy, *" versucht und nun geht es und grade beim Schreiben fällt mir was auf.
Das Feld "NULL" war bestimmt zwei mal drin, wegen dem * (anfangs war das bestimmt noch tabelle.*)
[edit] Nee, es war doch "SELECT xxx, yyy, tabelle.*" und jetzt mit "SELECT tabelle.*, xxx, yyy" geht es und außerdem hab ich die Reihenfolge der Felder in der Query-Komponente umgedreht, so wie es Jetzt im Query steht.
[edit2] Letzteres hat keinen Einfluß.

[Perlsau]

Bequemer und eleganter find ich's, mit Views zu arbeiten: Du legst deine Joins praktisch schon in der DB an und kannst dann darin nach Herzenslust blättern und sortieren.

[Hansa]

Views eleganter ? Dann erkläre mal bitte, wie ich die Daten einer Tabelle abrufe, sagen wir mal Artikel von Nr. 1 bis 1000 bestückt. Ich will aber jetzt aus meinem Delphi-Prograam nur die von 100 bis 199 sehen.

[himitsu]

Beim View kann man ja auch ein WHERE oder sowas wie LIMIT, STARTS usw. verwenden
und ein ordentliches DBMS kann das genau so schnell und optimal auflösen, als wenn man das SELECT direkt verwendet.
Der View ist logisch gesehen wie eine virtuelle Tabelle und lässt sich fast genauso verwenden. (nur beim Beschreiben trifft man auf die selben Probleme wie beim JOIN ... also wenn es um das zurückschreiben geht.)

Solange es kein Writable-View ist, kommt doch am Ende genau das Selbe raus ... nur mit nocheiner Zwischenschicht, die man erstmal schreiben muß.
Da ich diese Tabelle aktuell nur einmal benutze, ist es doch erstmal keine Vereinfachung.

[Dejan Vu]

Auch eine VIEW mit JOINs kann man beschreiben, wenn das RDBMS das unterstützt. Es muss sich nur jedes Feld der View auf ein Feld der darunterliegenden Tabelle abbilden lassen.

Natürlich muss ich eine VIEW entsprechend formulieren, wenn ich windowing funktionen verwenden, und dabei nicht ewig warten will. Ich persönlich find es es jedoch auch eleganter, eine Trennung einzuziehen und Zugriffe der Applikationen nur über Views und SP zuzulassen. Dann kann ich die DB-Struktur nach Herzenzlust ändern, ohne meine Programme anfassen zu müssen.

[Perlsau]

Zitat von Hansa:

Views eleganter ? Dann erkläre mal bitte, wie ich die Daten einer Tabelle abrufe, sagen wir mal Artikel von Nr. 1 bis 1000 bestückt. Ich will aber jetzt aus meinem Delphi-Prograam nur die von 100 bis 199 sehen.

Gerne, obwohl du das sicher auch selbst weißt, weil es so simpel ist:

Code:

select * from MyView where ArtikelNummer < 1001;
select * from MyView where ArtikelNummer > 99 and ArtikelNummer < 200;

In deiner Delphi-Anwendung arbeitest du dann mit Filtern, nachdem du im SQL-Property deiner Query-Komponente select * from MyView angegeben hast:

Delphi-Quellcode:

Datenmodul.Query_MyView.Filter := 'ArtikelNummer > 99 and ArtikelNummer < 200';
Datenmodul.Query_MyView.Filtered := True;

Einer meiner zahlreichen Views sieht z.B. so aus:

Code:

CREATE OR ALTER VIEW V_HOERBUCH(
    ID,
    TITEL,
    HOERART,
    AUTOR,
    KATEGORIE,
    SPRACHE,
    VORLESER,
    SPIELDAUER,
    ANZAHL,
    QUELLE,
    URL,
    GESEHEN,
    MARKIERT,
    NOTIZEN)
AS
select

HOERBUCH.ID_HOERBUCH,
HOERBUCH.TITEL,
BUCHSPIEL.HOERART,
AUTOREN.NAMEFULL,
KATEGORIEN.KATEGORIE,
SPRACHEN.SPRACHE,
VORLESER.NAMEFULL,
HOERBUCH.SPIELDAUER,
HOERBUCH.ANZAHL,
QUELLEN.QUELLE,
HOERBUCH.URL,
HOERBUCH.GESEHEN,
HOERBUCH.MARKIERT,
HOERBUCH.NOTIZEN

from HOERBUCH

inner join BUCHSPIEL  on BUCHSPIEL.ID_BUCHSPIEL   = HOERBUCH.HOERART
inner join AUTOREN    on AUTOREN.ID_AUTOREN       = HOERBUCH.AUTOR
inner join KATEGORIEN on KATEGORIEN.ID_KATEGORIEN = HOERBUCH.KATEGORIE
inner join SPRACHEN   on SPRACHEN.ID_SPRACHEN     = HOERBUCH.SPRACHE
inner join VORLESER   on VORLESER.ID_VORLESER     = HOERBUCH.VORLESER
inner join QUELLEN    on QUELLEN.ID_QUELLEN       = HOERBUCH.QUELLE
;

Man sieht, das ist letztendlich einfacher zusammenzubauen als ein komplizierter SQL-Befehl in deiner Anwendung. Ein weiterer Vorteil von Views besteht darin, daß ich in einer Query, die eine View-Datenmenge selektiert, direkt auch nach den Inhalten der verlinkten Sub-Tabellen sortieren kann, z.B.:

Delphi-Quellcode:

Procedure TDatMod.SortierenHoerbuch(Spalte: Integer);
Const
  K = ';';
  SortText = ' Hörbücher sortiert nach "';

Var
  SortAus,
  SortOrd,
  SqlSort : String;

begin
  If GLD.URec.HB_SortOrd Then
  Begin
    SortOrd := '" aufwärts';
    SqlSort  := ':A';
  End Else
  Begin
    SortOrd := '" abwärts';
    SqlSort := ':D';
  End;

  Case Spalte Of
   0 : Begin
         Tab_V_Hoerbuch.IndexFieldNames := 'TITEL'      + SqlSort + K + 'AUTOR'     + SqlSort + K + 'VORLESER' + SqlSort + K +
                                           'SPRACHE'    + SqlSort + K + 'KATEGORIE' + SqlSort + K + 'HOERART'  + SqlSort + K;
         SortAus := 'Titel';
...

[himitsu]

Zitat von Perlsau:

Man sieht, das ist letztendlich einfacher zusammenzubauen als ein komplizierter SQL-Befehl in deiner Anwendung.

Nee, nix einfacher ... es ist genau das Selbe.
Einfach das CREATE VIEW ... AS weglassen und schon hat man das selbe SELECT-Statement, welches man direkt im Programm verwenden kann.

Zitat von Perlsau:

Ein weiterer Vorteil von Views besteht darin, daß ich in einer Query, die eine View-Datenmenge selektiert, direkt auch nach den Inhalten der verlinkten Sub-Tabellen sortieren kann, z.B.:

Und das Sortieren geht natürlich auch ohne VIEW problemlos ... 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.