Hallo Artur,
in so einem Fall würde ich die gesamten Datenbankzugriffe in ein Datenmodul legen und dieses Datenmodul in alle Programme einbinden. Dadurch kannst Du dann die gesamte Datenbankschnittstelle in diesem Modul pflegen, die Änderungen sind aber in allen Programmen beim nächsten Kompilieren vorhanden. Eventuelle "Quelltextredundanzen" (also (annähernd) identische Quelltextteile in verschiedenen Formularen... können entfallen).
Deine Prozedur
procedure TReplicatorForm.WriteSQLMessageToDB(MsgText : string);
würde dann mit dem gesamten Inhalt z. B. zu
procedure TDatenmodulVertrieb.WriteSQLMessageToDB(MsgText : string);
Eventuell machst Du aber aus der Prozedur eine Funktion, damit Du im aufrufenden Programm... den Erfolg oder Misserfolg abfragen kannst:
Delphi-Quellcode:
function TDatenmodulVertrieb.WriteSQLMessageToDB(MsgText :
string) : Boolean;
var
TextFile : TStringList;
TextFileName :
string;
FS : TFormatSettings;
begin
Result := false;
// Wir gehen erstmal von einem Misserfolg aus.
try
if not trClntWr.InTransaction
then trClntWr.StartTransaction;
with quClnt2
do
begin
SQL.Clear;
SQL.Add('
INSERT INTO SQL_MESSAGE ');
SQL.Add('
(DB_VERSION, MSG_FROM_PROCEDURE, MSGTEXT, PROG_VERSION, HOST_ID, PC_NAME) ');
SQL.Add('
VALUES ');
SQL.Add('
(:DBVersion, :FromProcedure, :MsgText, :ProgVersion, :HostID, :PCName)' );
ParamByName('
DBVersion').AsString := FClntDBVersion;
ParamByName('
FromProcedure').AsString := '
TReplicatorForm';
ParamByName('
MsgText').AsString := Copy(MsgText,1,12000);
ParamByName('
ProgVersion').AsString := Opts.VersionInfo;
ParamByName('
HostID').AsString := FClientID;
ParamByName('
PCName').AsString := Opts.DBHostName;
ExecQuery;
end;
trClntWr.Commit;
Result := True;
// Erfolgreich sind wir nur, wenn wir das Commit "überstanden" haben.
except
TextFile := TStringList.Create;
try
FS := TFormatSettings.Create('
de-DE');
FS.DateSeparator := '
.';
FS.TimeSeparator := '
-';
TextFile.Add(MsgText);
TextFileName := GetIniFilePath + '
\RepLog_' + DateTimeToStr(Now,FS) + '
.txt';
TextFile.SaveToFile(TextFileName);
finally
TextFile.Free;
end;
end;
end;
Der Aufruf in Deinen Programmem könnte dann in etwa so aussehen:
Delphi-Quellcode:
procedure TReplicatorForm.WriteSQLMessageToDB(MsgText : string);
begin
if not DatenmodulVertrieb.WriteSQLMessageToDB(MsgText) then begin
ShowMessage('Die Meldungen konnten leider nicht geschrieben werden.');
// Oder halt irgendwelche sonstigen Fehlerbehandlungen, sofern erforderlich.
end;
end;
Im Idealfall erfolgt eine strenge Trennung zwischen den Datanbankroutinen und der optischen Darstellung der Daten und der übrigen Geschäftslogik.
Im Extremfall könntest Du dann durch Austausch des Datenbankmoduls ohne Änderungen an den übrigen Programmen auf die Datenbank eines anderen Herstellers wechseln, sofern nicht alle Datenbankzugriffe für alle Datenbanken kompatibel sein sollten.
Letztlich entsteht durch das Datenmodul ein eigenes Objekt bzw. eine Klasse zur Verfügung, die die gesamte Datenbankschnittstelle kapselt. Hierdurch lassen sich Redundanzen (annähernd) identischer Quelltext in vielen Programmen, Formularen, Units... vermeiden. Der anfänglische Mehraufwand für das Design des Datenmoduls lohnt sich bei der weiteren Entwicklung und Pflege der Software sehr schnell.
Jedes neue Programm oder Modul verfügt alleine durch das Einbinden des Datenmoduls sofort über die komplette Datenbankschnittstelle.
Zugegeben: So eine Schnittstelle nachträglich in bereits bestehende Programme und Module einzubauen ist eine Herausforderung und erfordert eine grundlegenden Analyse des Vorhandenen und einer fundierten Planung. Aber der Aufwand kann sich durchaus (auch oder gerade bei noch wachsenden Projekten) lohnen.