Programm startet nicht auf anderem PC

[Int3g3r]

Guten Abend

Ich habe ein Programm geschrieben (win32-i386).
Dieses startet wie gewohnt auf dem Rechner auf dem ich es programmiert habe.
Es lässt sich in der IDE, per Debugger starten.
Es lässt sich auch starten ohne das Lazarus offen ist.
Es funktioniert einwandfrei auf dem PC auf dem ich es programmiert habe.
(Windows 10 Pro 64x, 22h2, Lazarus 2.2.2)

Wenn ich nun die exe auf einen anderen PC übertrage und diese starte passiert gar nichts.
- Das Programm wird nicht im Taskmanager angezeigt
- Ich erhalte keine Fehlermeldung beim starten.
- Wenn ich das Programm per CMD starte erhalte ich keinen Fehler.
- Windows 10 Pro 64x, 21h1
- Habe dies auf 2 anderen Rechnern getestet, startet bei beiden nicht.

Es passiert einfach gar nichts. Wie ich es nicht gestartet hätte.

Verwendete Uses:

Code: Alles auswählen

uses
  Classes, SysUtils, DB, ZConnection, ZDataset,
  Dialogs, IniFiles;                
 
uses
  Classes, SysUtils, Forms, Controls, Dialogs, Buttons, DBGrids, Variants,
  DBCtrls, LCLType, StdCtrls, ExtCtrls, ComCtrls, Grids, Graphics, System.UITypes, Clipbrd; 

Wie hier zu sehen verwende ich Zeos für eine sqlite3 Datenbank.
Habe bereits die Datenbankverbindung auskommentiert dies hat nichts bewirkt.

Hat jemand eine Idee an was das liegen könnte?
Wie kann ich das herausfinden?

Mfg Int3g3r

[af0815]

Wenn sqlite im spiel ist, so immer darauf achten, das die Treiber dafür vorliegen. Am besten mal die Treiber in das Verzeichnis der Exe kopieren. Was ganz blöde ist, wenn die Treiber auf den einem PC win32 sind und am anderen win64, dann sucht man sich blöd.

Die Connections der DB im Designer nie auf Active gestellt lassen, immer erst im Code aktivieren.

[charlytango]

sind das die uses aus einer oder zwei Forms? Classes und SysUtils wären doppelt - keine Ahnung ob das überhaupt etwas ausmacht, aber da müsste der Compiler meckern.

aktuell verwende ich für die DB-Anbindung ein ähnliches folgendes Konzept wie af0815:

die Connection wird sicherheitshalber als erstes im Code geschlossen, falls ich wieder vergessen habe sie in der GUI zu deaktivieren.

ich habe zwei Verzeichnisse unterhalb des Applikationsverzeichnisses.
dll ... das sind die 64bit dlls drin
dllx86 .. da sind die 32bit dlls

mit:

Code: Alles auswählen

function GetTargetCPUinfo: string;
begin
  result := {$I %FPCTARGETCPU%};
end; 

entscheide ich im Programm aus welchem Verzeichnis ich die dll nehmen muss.
Die LibraryLocation weise ich demnach erst im Programm zu.

Code: Alles auswählen

procedure EstablishDatabaseConnection
var
	libname:string;
begin
	libname:='libmysql.dll';
	if Zconnection1.Connected then zconnection1.Disconnect;
	if GetTargetCPUInfo='i386' then
	  Zconnection1.LibraryLocation:= Application.Location + 'dllx86'+DirectorySeparator+libname
	else
	  Zconnection1.LibraryLocation:= Application.Location + 'dll'+DirectorySeparator+libname;

	try
	  Zconnection1.Connect;
	except
	  on E:Exception do begin
		showmessage('Keine Verbindung zur Datenbank'+LineEnding+LineEnding+E.Message)
	  end;
	end;

end;//EstablishDatabaseConnection
 

Das verhindert zumindest dass sich das Programm wegen mangelnder bitness aufstellt.

[gladio]

Das hat wohl erst mal nichts mit der Datenbankanbindung zu tun.
Wenn da was nicht stimmt, müsste es Fehlermeldungen anzeigen.
Selbst bei falsch eingestelltem Zielsystem müsste eine Meldung beim Start kommen.

[af0815]

Es passiert einfach gar nichts. Wie ich es nicht gestartet hätte.

Einen Versuch gibt es noch, aktiviere im Projektmanager das Debugging und dreh alle Checks auf und binde die Zeilennummern mit ein. Dan mach ein clean Build und versuche es nochmals.

Debug Einstellungen

Screenshot 2022-12-13 064538.jpg (72.96 KiB) 1283 mal betrachtet

Das ist übrigends eine STandardeinstellung von mir, solange das Projekt nicht wirklich fertig ist.

[gladio]

Gibt es im Programm, ganz weit vorne, noch bevor etwas angezeigt wird, eine
Bedingungsabfrage oder Fehlerbehandlung, die das Programm mit "halt" abbricht.
Wäre so ziemlich das Einzige, ohne irgendeine Meldung.
Selbst Sicherheitseinstellungen von Windows auf den Zielrechnern, die den Programmstart verhindern könnten,
würden irgendeinen Kommentar abgeben.

[fliegermichl]

Starte das Programm mal aus einer DOS Box. Vielleicht bekommst du da eine Fehlermeldung angezeigt.

[charlytango]

nur weil es mich gerade selber erwischt hat:
Programm startet nicht.

War bei mir ein

Code: Alles auswählen

raise Exception.Create( 'irgendeine Message'); 

das aus unerfindlichen Gründen das nachfolgende Programm still gekillt hat. In der IDE gab es dann nach sauberem Neukompilieren einen Exit-Code 217 (https://stackoverflow.com/questions/213 ... itcode-217) was mir aber auch nicht weiter half.
In meinem Fall konnte ich das Raise durch ein showmessage ersetzen was dann geklappt hat.

[Int3g3r]

WoW hier haben aber viele geantwortet.
Danke für die Hilfe und Inputs.

Die Connections der DB im Designer nie auf Active gestellt lassen, immer erst im Code aktivieren.

af0815 hatte aber Recht.
Ich habe im Datenmodul die TZConnection auf "Connected=true".
Somit habe ich mal zum Test Connected auf false gesetzt.
Siehe da, es läuft alles.

Ich dachte ich hätte dies im OnCreate-Event des Datenmoduls abgefangen.
Theoretisch sollte ja beim erstellen des Datenmoduls direkt die Verbindung getrennt werden.
Somit vermute ich das er vorher in einen Fehler läuft weil er die Datenbank nicht findet die in der IDE hinterlegt ist.
Warum ich aber keine Fehlermeldung oder Exception erhalten habe ist mir weiterhin schleierhaft.

Das erste was ich mache ist die Verbindung zu trennen, schneller geht es nicht.
Das Datemodul wird auch als erstes erstellt.

Code: Alles auswählen

procedure TdmMain.DataModuleCreate(Sender: TObject);
begin
  DBConnect;
end;     

procedure TdmMain.DBConnect;
begin
  dbConn.Disconnect;
  dbConn.Connected := false;
  if (FileExists(IniFileName)) then
  begin
    iniRead;
    dbConn.Connected:= false;
    dbConn.Database:= SettingsRec.database;
    dbconn.LibraryLocation := SettingsRec.sqlite3dll;
  end;
  if (SettingsRec.autoconnect = true) then
  begin
    try
          dbConn.Connect;
          qryOpen;
    except
          ShowMessage('Verbindung zur Datenbank konnte nicht hergestellt werden...');
    end;
  end;
end;   

[MmVisual]

Bei Zeos gibt es in TZConnection den Parameter "DesignConnection", setze den auf TRUE, dann wirst du dieses Problem nie wieder haben, da dann Zeos automatisch beim Start der EXE immer den "Connected" auf False setzen wird.

[wp_xyz]

Ich dachte ich hätte dies im OnCreate-Event des Datenmoduls abgefangen.

Bis das OnCreate-Event kommt, ist die lfm-Datei schon gelesen und der Fehler bereits aufgetreten.

War denn auf dem zweiten Rechner der Pfad zur Datenbank-Datei derselbe wie auf dem ersten? Wenn nicht, würde das erklären, dass die Anwendung beim Lesen der lfm-Datei abstürzte (weil wegen Connected = true eine Verbindung zur nicht-gefundenen Datenbank herstellt werden sollte). Warum das keine Fehlermeldung hinterlassen hat, kann ich nicht sagen.

[af0815]

Ich dachte ich hätte dies im OnCreate-Event des Datenmoduls abgefangen.

Das geht nicht, weil das OnCreate Event genaugenommen zu spät ist. Das Problem ist dabei, wenn das Datenmodul hereingestreamt wird, werden die entsprechenden Properties gesetzt und jetzt schlägt das System zu, weil eventuell notwendige Einstellungen noch nicht getroffen wurden.

Es spielt bei vielen, besonders unter Linux keine Rolle, weil zum Beispiel alle Treiber am System sind und auch richtig erkannt werden. Wenn diese Applikation dann auf ein System kommt, wo diese Abhängigkeit nicht vorhanden ist oder auf eine andere Plattform portiert wird, so wird es sehr öde und man darf sich mit sowas herumschlagen.

Deswegen habe ich mir schon zu Delphis zeiten angewöhnt, nur eine Form wird automatisch erstellt und die mach t im ersten OnActivate ALLE Initialisierungen und erstellt auch alle (visuellen)Objekte. Damit geht man auch dem Abhängigkeitsproblem aus dem Weg, das kommt, wenn die Reihenfolge der Forms und Datenmodule im der Projektdatei sich (aus welchen Grund auch immer) ändert. Das ist genauso gefährlich und man sucht sich einen Wolf, warum das Programm nach einer Mikey Maus Änderung plötzlich zerstört erscheint.