Absturz des SQL-Editors in der IDE (D7/ADS10.1)

[haentschman]

Hallöle...

Deine Gedanken sind richtig. Wie leicht kannst du noch einen Schritt weiter machen...

Zitat:

Würdet Ihr von einer zentralen Stelle mit den SQL-Queries gleich eine Query-Komponente zurückgeben

Ja...zentral. Hier bietet sich eine abstrakte Klasse oder Interface je DBMS an. Die Anwendung kennt kein DBMS. Sie arbeitet auf Dataset Ebene oder mit Listen. (Beispiel: GetDatabaseVersion)

Delphi-Quellcode:

function TDatabase.CreateQuery: TUniQuery;
begin
  Result := TUniQuery.Create(nil);
  Result.Connection := FMeineConnection;
end;
...
procedure TDatabase.GetDatabaseVersion;
var
  Query: TUniQuery;
begin
  Query := CreateQuery;
  try
    Query.SQL.Text := 'SELECT F_VERSION FROM T_VERSION';
    Query.Open;
    FDatabaseVersion := Query.FieldByName('F_VERSION').AsInteger;
  finally
    Query.Free;
  end;
end;
...
procedure TDatabase.FillQuery(Query: TDataSet);
  Query: TUniQuery;
begin
  Query := CreateQuery;
  Query.SQL.Text := 'SELECT F_BlBB FROM T_BLA';
  Query.Open;
end;

Zitat:

oder nur einen SQL-String für eine Komponente?

Du hast keine Komponenten mehr auf der Form. Das Statement ist in der Klasse definiert. Query.SQL.Text := 'SELECT F_VERSION FROM T_VERSION' Die Funktion gibt das neuerzeugte TDataSet oder die Liste zurück...enweder als Result oder var Parameter.
Eine andere Möglichkeit ist die Statements extern zu verwalten in Ressourcen. Wenn du es wissen willst kann ich nochmal darauf eingehen.

Zitat:

Nachteil wäre, dass ich (in der IDE) keine persistenten Felder mehr nutzen kann, an die ich z.B. Standard-AufbereitungsRoutinen (in OnGetText) hängen kann.
Die Aufbereitung von Feldern z.B. für ein TDBGrid müsste dann auch im Grid erfolgen.
Ebenso müsste ich auf Lookup-Felder verzichten

Wenn du die datensensitiven Komponenten wegläßt, hast diese Probleme nicht mehr. Wenn du dir Datenklassen baust, kannst du auch komplexe Daten an die Nodes oder Zeilen hängen.

Zitat:

Die Aufbereitung von Feldern z.B. für ein TDBGrid müsste dann auch im Grid erfolgen.

Die Berechnerei kannst dann in der Klasse erledigen statt im Visuellen Control. Das macht dich unabhängig...

Zitat:

Wenn man den Parameter-Gedanken weiterspinnt, dann wäre es doch sinnvoll, für jede Abfrage eine eigene Routine zu machen, die ein Query liefert und konkret benannte und typisierte Werte entgegen nimmt. Andernfalls müsste ich immer die Parameter-Namen bzw. -Positionen nachschlagen

Jawoll..ja.

Wenn man weiterspinnt...

Delphi-Quellcode:

function TDatabase.Save(Blubb: TBlubbClass): Integer;
var
  Qry: TUniQuery;
begin
  Result := -1;
  Qry := CreateQuery;
  try
    case Blubb.State of
      ddsNew:
        begin
          Qry.SQL.Text := GetSQLByName('SER_INSERT_BLUBB'); // aus Ressource
          Qry.ParamByName('UID').AsInteger := Blubb.UserID;
          Qry.ParamByName('GRO').AsString := Blubb.Group;
          Qry.ParamByName('DEF').AsInteger := 0;
          Qry.ExecSQL;
          Blubb.ID := Qry.ParamByName('RET_ID').AsInteger; // neue ID direkt im Objekt ... geht bei Firebird
          Result := Blubb.ID;
        end;
      ddsEdit:
        begin
          Qry.SQL.Text := GetSQLByName('SER_EDIT_BLUBB');
          Qry.ParamByName('GRO').AsString := Blubb.Group;
          Qry.ParamByName('ID').AsInteger := Blubb.ID;
          Qry.ExecSQL;
          Blubb.State := ddsNormal;
          Result := Blubb.ID;
        end;
      ddsDeleted:
        begin
          Qry.SQL.Text := GetSQLByName('SER_DELETE_BLUBB');
          Qry.ParamByName('ID').AsInteger := Blubb.ID;
          Qry.ExecSQL;
          Result := Blubb.ID;
        end;
    end;
  finally
    Qry.Free;
  end;
end;

...das Objekt kennt seinen Status. Dann speichere mal mein Blubb Objekt mit DatabaseInstanz.Save(Blubb) ...fertsch.


Weiter so...