Keine Datenverbindung, wenn DataSource in einem Datenmodul liegt (Gelöst)

[walsch.rene@web.de]

Guten Tag. Ich programmiere seit 30 Jahren als Hobby in TurboPascal, Delphi und nun FPC. Daran werdet Ihr zweifeln, wenn Ihr meinen ersten Post in diesem Forum lest:

Ich habe ein DBGrid mit einer DataSource verbunden. Lege ich DataSet und DataSource auf dem Formular ab, wird die Feldstruktur im Grid angezeigt, Daten können zur Laufzeit manipuliert werden. So soll es sein.
Lege ich beides in ein Datenmodul, können zur Laufzeit keine Daten manipuliert werden, als wäre das DBGrid mit keiner DataSource verbunden bzw. der DataSet nicht Active. Das Datenmodul ist via uses in Form1 eingebunden. Ich bekomme die DataSource, die im Datenmodul liegt, im Objektinspektor angeboten. Ich erhalte beim Kompilieren der Form sogar den Hinweis, dass ich die unit zwar eingebunden habe, aber nicht verwende. Sämtliche Komponenten werden zur Design-Zeit definiert und aktiviert. Dateien anbei.

Vielen Dank für Eure Hilfe!
René

[charlytango]

- beim schnell mal drübersehen ist mir aufgefallen dass das Datamodul nicht (automatisch) erzeugt wird. (siehe -> Projektoptionen - Formulare)

- des weiteren ist DbfBAYNos als Komponente nicht aktiv und im Code nie geöffnet worden, kann also keine Daten liefern

Code: Alles auswählen

//ins Open-Event (bzw Activate oder Show je nach Einsatzart des Formulars)
if not dm.DbfBAYNos.Active then dm.DbfBAYNos.Open ;

- in der zip-Datei des projektes fehlt auch die baynos.dbf um es auszuprobieren

BTW: obwohl ich sicher mehr als eine Dekade damit zu tun hatte, sind dBase-Dateien und deren Artverwandte heute nicht mehr meine DB der Wahl. Auch lokal verwende ich mittlerweile SQL Datenspeicher (zb SQLite) - wenn du mehr darüber wissen willst einen eigenen Thread oder PM

[walsch.rene@web.de]

Vielen Dank für die Antwort. Da ich sie nicht verstehe, hat es mit meiner nun eine Weile gedauert.

Mein Wissen stammt v.a. aus Delphi, dort habe ich zur Entwurfszeit alles zusammengeschoben, verbunden und aktiviert, selbst bei MS Access-Datenbanken. Ein DBGrid oder ähnliches DataControl zusammen mit einem DBNavigator genügten stets für eine volle Datenbankfunktionalität (Hinzufügen, Editieren, Speichern, Löschen, Lookup-Fields usw.), ohne eine einzige Zeile eigenen Programmcode. Das Datenmodul habe ich nie "erzeugen" müssen. Daher sagt mir "... dass das Datamodul nicht (automatisch) erzeugt wird. (siehe -> Projektoptionen - Formulare)" leider überhaupt nichts.

Wenn DbfBAYNos auf dem Formular statt im Datenmodul liegt, funktioniert in FPC alles bestens. Daher verstehe ich nicht, weshalb ich sie zur Laufzeit noch einmal aktivieren soll, obwohl sie zur Entwurfszeit bereits aktiviert ist. Ich hatte eine Zeile ähnlich der von Ihnen vorgeschlagenen auf das Ereignis FormMain.OnShow programmiert, was zum Laufzeitfehler führte (ich nehme an, weil ein aktivierter Dataset nicht aktiviert werden kann, Ihr Code ist eleganter). Auch Open ist dann nicht erforderlich, jedenfalls kann ich problemlos Datensätze hinzufügen, ändern, speichern und löschen, was ohne Open wohl nicht möglich wäre. Wie es aussieht, gibt es zwischen Delphi und Lazarus doch Unterschiede bei der Datenanbindung, mit denen ich nicht gerechnet hatte.

Die baynos.dbf befindet sich im Unterverzeichnis dbase. Natürlich ist DBase sowas von 1990 Ich möchte eine kleine DB-Anwendung für meine Arbeit programmieren, habe aber keine Adminrechte. Auch findet sich unter den ODBC-Einstellungen der Win10-Systemsteuerung der Treiber "MSAccess DB, .mdb, .accdb" nicht mehr, was mir ein Rätsel ist, da ich MSAccess auf dem Rechner habe. TODBCConnection fällt also aus. DBase kommt ohne Treiber aus, daher meine altmodisch anmutende Wahl.

Beste Grüße,
René

[af0815]

Lazarus ist nicht Delphi !!!

Die Grundlagen sind ähnlich, die IDE aber nicht. Ich habe festgestellt dasich mit Delphi keine Applikation so mehr einfach hinbekomme. Umgekehrt muss es ähnlich sein. ABER mit den Hinweisen muss man sich beschäftigen.
Das Datamodul muss entweder im Hauptformular im Code erstellt werden oder automatisch. Das ist auch in Delphi so.
Dein Problem ist, wann wird das Datamodul erstellt und verwendet. Wenn du dem Henne - Ei Problem entgehen willst, so lege es auf das Formular, ansonsten wirst du dich damit beschäftigen müssen, wann etwas erstellt wird. Da gibt es wenig Unterschied zu Delphi. Das Problem kenne ich seit Jahren.

[walsch.rene@web.de]

Okay, danke.

[af0815]

Warum ich die 'automatische' Verbindung generell vermeide bzw. deaktiviere:

Wenn du ein Datenmodul hast, so wird es zu einem nicht genau kontrollierbaren Zeitpunkt aktiviert und die Verbindung zur Datenbank aufgebaut. Das heisst aber, das du nicht weist in welchen Zustand die verknüpften datensensitiven optischen Komponenten sind. Sind die schon fertig erstellt bzw. bereit oder ist das Formular wo diese Komponenten draufliegen vielleicht noch gar nicht fertig initialisiert.

Meiner Erfahrung nach, ist es am sichersten wenn man nur EIN automatisch erstelltes Formular hat und dort gezielt die anderen Forms und Datenmodule erzeugt und startet. Damit ist man auch nach Jahren sicher das das programm stabil ist und nicht eine 'kleine' Änderung ungeahnte Seiteneffekte zieht. Ich mache das über eine Variable Init im Hauptformular und beim ersten OnActivate mache ich die ganzen Initialisierungen einmalig und setze die Variable. Damit weis ich, das ich alles fertig initialisiert habe. Damit ist es auch möglich, die ganzen Datenbankverbindungen per Parameter zu konfigurieren und nicht fix im Quelltext.

Diese Vorgangsweise hat sich vor Jahren bei Delphi (und Vorläufern) bewährt und das habe ich nach Lazarus übernommen. Aber jeder hat im laufe der Jahre so seine Rezepte.

[charlytango]

ich habe dir als Quickhack mal deinen Code zum Laufen gebracht.

• in den Projektoptionen habe ich dafür gesorgt dass das Datamodule automatisch erzeugt wird (Ctrl+Shift+F11 und auf der Ebene "Formulare" das Datamodule in die Liste der Auto-Create-Forms geschoben). Das ist in Delphi übrigens nicht anders. Ob das in jeder denkbaren Situation auf diese Weise klug ist, hat @af0815 schon angerissen.

• Des weiteren hab ich in DbfBAYNos den Pfad zur dBase Datei korrigiert und aktiv gesetzt.

-> damit funktioniert das Teil auch schon mal im Designmodus.

um etwas allgemeingültiger zu sein habe ich noch etwas Code hinzugefügt

Code: Alles auswählen

procedure Tdm.DataModuleCreate(Sender: TObject);
begin
  if DbfBAYNos.Active then DbfBAYNos.Close;
  DbfBAYNos.FilePath:='\dbase\';
  DbfBAYNos.Open;
end; 

Dann sollte zur Laufzeit egal sein wie deine Verzeichnisstruktur aussieht.

[walsch.rene@web.de]

Wow, ganz herzlichen Dank!
Ich denke, damit komme ich weiter.

Beste Grüße,
René

[charlytango]

gern geschehen....

Nur löst das dein ursprüngliches Problem nicht.

Lazarus ist nicht Delphi !!!

Natürlich hat af0815 damit Recht. Vollkommen!
Trotzdem kann man einfache Anwendungen wie bei Delphi zusammenklicken.
Wenn man mehr haben wollte war das auch schon in Delphi (m)ein Problem.
Letzlich blieb von den vielen Automatismen nur eine Handvoll übrig, vor allem wenn es um das Zeichnen von Eingabeformularen ging.

Der Rest lässt sich besser und stabiler kontrollieren wenn man Objekte (alo auch Formulare) selbst erzeugt. Es wird also nur ein einziges (Haupt)Formular automatisch erzeugt und alles andere wird im Programmcode geregelt. Dann hast du zwar etwas mehr Arbeit aber die Sicherheit das alles so (und zum richtigen Zeitpunkt) passiert wie du es brauchst.

Braucht etwas, ist aber leichter als man denkt. Und bei Fragen gibts ja das Forum hier.
Nur nochmal meine Meinung: Ich würde den Aufwand nicht scheuen und SQLite (oder was ähnliches) nutzen um dBase in Pension zu schicken.

[walsch.rene@web.de]

Nochmals vielen Dank, charlytango!

Wie gesagt, ich bin nicht der Admin und werde auf einem Firmenrechner nichts installieren (können) als Portable-Versionen. Sollte es eine SQL-basierte DB geben (die ich also mit TSQLQuery befragen kann), die ich ohne Admin-Rechte installieren kann - perfekt. Bei SQLite scheint das so zu sein, ich werde es mir mal anschauen. Was wäre denn "was ähnliches", damit ich mir auch das anschauen kann?

Vielen Dank, René

[charlytango]

schau mal hier

Ich denke Firebird käme noch in frage, da bin ich aber nicht wirklich bewandert. Auch MSSql hat ja schon länger Desktopversionen.

Für einen problemlosen Einsatz unter den genannten Bedingungen würde ich eine DB empfehlen die einfach nur die DB-Datei (also die Daten) und eine Zugriffs-DLL in einem Verzeichnis voraussetzt (also keine wirkliche "Installation") . Dann brauchst du keinen eigenen DB-Service-Prozess, das macht die DLL gleich mit.
Wie gesagt, ich nehme dazu SQLite. Durchaus im Bewusstsein dass sie ihre Herausforderungen mit bestimmten Feldformaten hat. Trotzdem halte ich das immer noch für besser als dBase-Derivate, denn mit ein bisschen Gehirnschmalz kann man leicht auf 'echte' DBs wechseln.

Vielleicht ist auch XAMPP einen Blick wert.

[af0815]

Wenn fpc/Lazarus am Rechner funktionieren - es geht mit fpcupdeluxe auch im Benutzerbereich - so ist sqlite nur eine dll die du 2 x kopieren musst. Einmal ins Lazarus Verzeichnis und einmal in das Verzeichnis deines Programms - wo die ausführbare Datei liegt. Achtung, das du die richtige version erwischt (32Bit und 64 Bit Version).

Ich habe mit eingeschränken Rechten, Lazarus im Benutzerverzeichnis zum laufen gebracht. Ist zwar ein paar Tage her, aber es ging. DIe fertigen Installationspakete haben damals nicht funktioniert - zu wenig Rechte.

[gladio]

Achtung, das du die richtige version erwischt (32Bit und 64 Bit Version).

Das richtet sich nicht nach der Bitrate deines Systems oder des Zielsystems, sondern nach der Bitrate der fertigen EXE.
Aber das kannst du ausprobieren. Sind 50% Warscheinlichkeit auf Erfolg.
(gilt nur für SQLite)

[af0815]

Achtung, das du die richtige version erwischt (32Bit und 64 Bit Version).

Das richtet sich nicht nach der Bitrate deines Systems oder des Zielsystems, sondern nach der Bitrate der fertigen EXE.
Aber das kannst du ausprobieren. Sind 50% Warscheinlichkeit auf Erfolg.
(gilt nur für SQLite)

Nicht ganz korrekt. Zur Designtime wird die dll aus dem Lazarusverzeichnis verwendet (die muss zu der Bitness von Lazarus stimmen), wenn das Programm läuft/Debugged wird, die Version aus den Exe-Verzeichnis (die muss zur Exe passen). Es ist also vorprogrammiert, das man die falschen 50% erwischt

Unter Linux ist das einfacher, da wird das vom Sytem installierte genommen und dort gibt es fast keine (hallo RasPi) 32 Bit Anwendungen mehr

[gladio]

Ich stelle zur Designzeit die Librarylocation schon immer auf das jeweilige Arbeitsverzeichnis und lasse am Programmstart zur Laufzeit das EXE-Verzeichnis ermittel, damit dort die DLL geholt wird. Deshalb ist mir das wohl nicht so aufgefallen. Und auf 32 Bit bin ich auch nicht mehr unterwegs.