SDAC Connection...

[BigAl]

Hallo zusammen,

ich arbeite derzeit an einem Projekt, welches Daten auf einem MS SQL-Server verwaltet. Für den Zugriff nutze ich die SDAC-Komponenten von Devart. Ich habe damit folgende Probleme die ich mir einfach nicht erklären kann bzw. mich nicht daran erinnere, dass das früher auch so war:

- Es wird ein Datenmodul erstellt. Dieses wird in den Projektoptionen als erstes Form initialisiert (steht ganz oben über dem Hauptformular)
- Im Datenmodul wird eine Connection definiert (TMSConnection)
- Ein neues Formular wird erstellt. Dieses wird nicht automatisch erzeugt (was jedoch irrelevant ist).
- In der uses-Liste des Formulars wird die Unit des Datenmoduls aufgenommen (damit die Connection verfügbar ist).
- Auf dem Formular wird ein Query definiert welches die Connection aus dem Datenmodul verwendet.
- Das Query wird auf "Active" gesetzt.

Soweit erst mal alles Standard. Nun habe ich folgende beiden Probleme:

1. Wenn ich die Applikation starte steht das "Active" der Query auf "False". Ich kann diese aber Problemlos in Create der Form auf "True" setzen. Sollte die nicht automatisch auf "True" sein wenn es zur Design-Time auf "True" war?

2. Wenn ich das Projekt neu öffne (z.B. nach dem Start von Delphi) erhalte ich für alle aktiven Zugriffskomponenten (Query, Table, ...) die Meldung "Connection is not defined". Die Formulare werden zwar geöffnet aber Datenzugriffe sind inaktiv (Active = False).

Ich habe nun schon eine Weile nichts mehr mit Datenbanken gemacht und bin mir daher etwas unsicher. War das früher auch schon so? Muss ich zur Laufzeit jede benötigte Datenquelle wieder explizit öffnen? Konnten auch früher schon geöffnete Datenquellen nicht im Projekt gespeichert werden? Das Verhalten ist in Delphi 10.4 und Delphi 11 gleich...

Danke für eure Hilfe

Alex

[taveuni]

Bei mir sieht das seit Jahren immer so aus:

Delphi-Quellcode:

TServerDataModule = class(TDataModule)
private
FMsConnection: TMSConnection;
procedure Init;

var
  ServerDataModule: TServerDataModule;

implementation

procedure TServerDataModule.Init;
begin

  FMsConnection:= TMSConnection.Create(Nil);
  FMsConnection.Server:=    IniFile.ReadString('DataBase','Server','localhost');
  FMsConnection.Database:=  IniFile.ReadString('DataBase','Database','DatabaseName');
  FMsConnection.Username:=  IniFile.ReadString('DataBase','UserName','UserName');
  FMsConnection.Password:=  Decrypt(IniFile.ReadString('DataBase','Password','Password'),READ_KEY);

  ConnectDatabase; // da wird in einem Thread versucht zu verbinden.
end;


procedure TServerDataModule.IrgendeineDatebankfunktion;
var
  Qry: TMSQuery;
  Conn: TMSConnection;
begin
  Conn:= TMSConnection.Create(Nil);
  Conn.Assign(self.FMsConnection);
  Qry:= TMSQuery.Create(Nil);
  Qry.Connection:= Conn;
  Try
      Qry.SQL.Text:= 'SELECT * FROM whatever WHERE id =:id';
      Qry.ParamByName('id').AsInteger:= 12;
      Qry.Open;
      while not Qry.Eof do
      begin

        Qry.Next;
      end;
    end;
  Finally
    Conn.Free;
    Qry.Free;
  End;
end;

Das Assign der "globalen" Connection erlaubt problemloses Multithreading.

[BigAl]

Hallo taveuni,

was willst Du mir damit sagen? Es geht mir nicht um die Nutzung der Datenbank im Quellcode (das ist problemlos), es geht um die visuellen Komponenten. Ich habe jede Menge Tabellen, Views, Procedures usw. die zur Ein. und Ausgabe der Daten verwendet werden. Dazu werden die Standard DB-Komponenten eingesetzt. Dahinter befindet sich eine umfangreiche Datenbank mit sehr vielen, teils großen Tabellen (z.t. über hundert Felder pro Tabelle). Eine typische Datenbankanwendung eben...

Gruß
Alex

[taveuni]

Zitat von BigAl:

Hallo taveuni,

was willst Du mir damit sagen? Es geht mir nicht um die Nutzung der Datenbank im Quellcode (das ist problemlos), es geht um die visuellen Komponenten. Ich habe jede Menge Tabellen, Views, Procedures usw. die zur Ein. und Ausgabe der Daten verwendet werden. Dazu werden die Standard DB-Komponenten eingesetzt. Dahinter befindet sich eine umfangreiche Datenbank mit sehr vielen, teils großen Tabellen (z.t. über hundert Felder pro Tabelle). Eine typische Datenbankanwendung eben...

Gruß
Alex

Dann musst Du entschuldigen. Wir haben hier Datenbanken mit Millionen von Records, Stored Procedures und anderem welche wir als 3-Tier Entwicklungen den Clients zur Visualisierung bereitstellen. In Delphi auf der Clientseite dann eigentlich immer mit VirtualStringTree. Wenn Du von festen Verknüpfungen Dataset/Query/Grid in Standalone Applikationen sprichst - das haben wir noch nie gebraucht. Ich habe Dich offensichtlich falsch verstanden.

[BigAl]

Kein Problem . Ist halt eine andere Anwendung... Soll halt ein Client sein, der direkt mit der Datenbank verbunden ist.

[dataspider]

Hi Alex

Ich kenne es so - wie es sich bei dir zeigt, seit ich Delphi benutze.
Wenn die IDE beim Öffnen deines Projektes nicht das Datenmodul mit der Connection zuerst öffnet,
dann fliegen sogar deine Einstellungen ab und an raus.

Aus diesem Grund setze ich Alles (Connection Parameter, Query, Datasource etc.) zur Laufzeit im Code.

Frank

[BigAl]

Zitat von dataspider:

Hi Alex

Ich kenne es so - wie es sich bei dir zeigt, seit ich Delphi benutze.
Wenn die IDE beim Öffnen deines Projektes nicht das Datenmodul mit der Connection zuerst öffnet,
dann fliegen sogar deine Einstellungen ab und an raus.

Aus diesem Grund setze ich Alles (Connection Parameter, Query, Datasource etc.) zur Laufzeit im Code.

Frank

Hi Frank

Ja, bisher habe ich das auch immer so gemacht. Datenbank war halt bisher bei mir immer Mittel zum Zweck bzw. der Löwenanteil der Applikation hatte nichts mit der Datenbank zu tun. Diese wurde nur zur Datenspeicherung und Analyse verwendet. Die aktuelle Applikation ist halt etwas anderes. Die ist ein reines Frontend für eine Datenbank. Da wird es recht aufwändig wenn man alles manuell macht. Viele Tabellen/Views/Stored Procedures usw.. Und viele Beziehungen zwischen den Tabellen (Foreign Keys)... Die Zuweisung in den Grids usw. ist halt viel komfortabler wenn eine Abfrage auf dem Formular geöffnet ist...

Alex

[dataspider]

Zitat von BigAl:

Da wird es recht aufwändig wenn man alles manuell macht. Viele Tabellen/Views/Stored Procedures usw.. Und viele Beziehungen zwischen den Tabellen (Foreign Keys)... Die Zuweisung in den Grids usw. ist halt viel komfortabler wenn eine Abfrage auf dem Formular geöffnet ist...

Wenn du mit den Fehlermeldungen beim Start leben kannst, kannst du ja so weitermachen.
Ich gehe mal davon aus, dass du alle Datenmodule nicht von TDataModule, sondern einem eigenen TMyBaseDataModule abgeleitet hast.
Dann recht es ja, in diesem AfterConstruction zu überschreiben und dort über die Componenten deines DataModules zu iterieren.
Dann kannst du wenigsten geschlossene Querys öffnen etc.

Frank

[BigAl]

Hallo Frank,

im zentralen Datenmodul öffne ich lediglich die Connection (Und z.B. den TMSSQLMonitor). Alle Abfragen usw. befinden sich dort wo sie benötigt werden und nutzen diese zentrale Connection. Z.B. auf den Formularen oder halt im Quelltext der Formulare oder Funktionen. Bei der Initialisierung der Formulare öffne ich halt explizit das was benötigt wird. Das Program selbst initialisiert lediglich das Datenmodul und das Hauptformular. Alles andere ist dynamisch...

Alex