MS Access-Verbindung funktioniert nur in der IDE

[OsCor]

Liebe Helfer,

nachdem ich jetzt den richtigen Treiber für den Access-Zugang installiert habe, gibt es bei einer der Anwendungen ein merkwürdiges Phänomen: Im Entwurfsmodus wird die Datenbankverbindung über ADO korrekt durchgeführt und die verbundenen Tabellen werden im DBGrid angezeigt. Aber sobald ich die Anwendung aber starte, kommt die Meldung „Der Provider kann nicht gefunden werden. Möglicherweise ist er nicht richtig installiert worden." und am Schluss ein weiteres Fenster von wegen geschlossener Datenmenge.

Eine Testanwendung mit den gleichen Tabellen funktioniert tadellos.

Auch hier nochmal die Bitte um einen Hinweis.

Gruß
Oswald

[Redeemer]

Bittigkeit der IDE anders als dein Programm, sodass eine andere ODBCAD32 verwendet werden muss?

[OsCor]

Haha, wollte das gerade posten: Was ich nicht bemerkt hatte, war, dass die Testanwendung 32-bittig ist. Gerade ist mir das aufgefallen und ich habe auf 64 Bit umgestellt ---> Aus die Maus, rien ne va plus. Nach dem Zurückstellen auf 32 Bit läuft es wieder.
Also stellt sich jetzt die Frage, ob es eine Konfiguration gibt, mit der ich die Anwendung dazu bringe, auf eine MS-Access 2019-Datenbank etwa mit ADO-Table und Konsorten zugreifen zu können.

Danke fürs Mitdenken!
Oswald

[kompi]

So wie ich es aus dem anderen Post verstanden habe, hast du Office in der 64 bit Version installiert und nachträglich den 32 bit Datenbanktreiber.

Wichtig bei der Sache ist, dass die Adoconnection nicht schon in der IDE verbunden ist, sondern erst während des Programmlaufs.
Ich löse das immer so, dass ich den Connectionstring in der Adoconnection zunächst während des Programmlaufs setze und anschließend Connection auf true setze.
Damit verbindet sich das Programm mit der Datenbank.
Funktioniert sowohl bei 32 als auch 64 bit.

Gruß Kompi

[OsCor]

Das klappt bei mir noch nicht ganz.
Ich setze beim Start der Anwendung den ConnectionString so wie ich ihn vorher in der IDE gesetzt hatte ('Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\XXXXXXX.accdb;Persist Security Info=False') und anschließend setze ich die Eigenschaft Active der Tabelle auf True. Das klappt aber nur bei der 32-bit Version. Fehlt da noch was?

Gruß
Oswald

[kompi]

Welche Komponenten verwendest du?
Ich verwende in meiner Anwendung eine Tadoconnection und nachgeschaltet eine Tadotable.
Gruß Kompi

[kompi]

Ich habe noch mal ein went das Internet bemüht. Es scheint so zu sein, dass die Office 2019 Installation bei CTR (Click to run) die ACE Databaseengine nicht mit installiert, sondern nur eine abgespeckt Engine. Also auch die 64 Bit Engine installieren.
Gruß Kompi

[Delphi.Narium]

Bau Dir mal in Dein Programm 'ne zusätzliche Funktion ein:

Delphi-Quellcode:

function GetConnectionString(Handle        : THandle;
                             ADOConnection : TADOConnection;
                             sConnection   : String = '') : Boolean;
begin
  ADOConnection.Connected        := False;
  // Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen, 
  // analog zu dem Aufbau per ObjektInspektor in der IDE.
  ADOConnection.ConnectionString := PromptDataSource(handle,sConnection);
  ADOConnection.Connected        := True;
  Result                         := ADOConnection.Connected;
end; 

// Irgendwo am Anfang, z. B. im FormCreate oder wo auch immer sonst
// die Datenbankverbindung bzw. die Tabellen geöffnet werden sollen:
begin
  if GetConnectionString(handle,ADOConnection1) then begin
    // Hier sollte die Datenbankverbindung bestehen.
    // Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
    // kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
    ShowMessage(ADOConnection1.ConnectionString);
  end else begin
    MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
  end;
end;

[OsCor]

Zitat:

Zitat von kompi (Beitrag 1516250)

Welche Komponenten verwendest du?
Ich verwende in meiner Anwendung eine Tadoconnection und nachgeschaltet eine Tadotable.

Genauso mache ich das auch.

Auch eine abgespeckte Engine müsste doch in der Appliste des Systems auftauchen, oder? Da ist bei mir nichts aufgeführt. Welche Engine verwendest denn du?
Außerdem: Wenn ich den 32-bit Treiber verwende, sehe ich ja, wie beim Aufbau des Connection-Strings innerhalb der IDE dieser String aussehen muss. Da muss ich erst mal sehen, wie der 64-bit String aussehen müsste.

@Delphi.Narium
Vermutlich stehe ich ziemlich auf dem Schlauch. Was verbessert sich für mich durch die zusätzliche Funktion?

Gruß
Oswald

[kompi]

Du hast ja auch den 32 Bit ACE Treiber installiert. Jetzt muss noch der 64 Bit ACE Treiber installiert werden. Der wird nicht mitinstalliert.
Gruß Kompi

[OsCor]

Klar. Aber da der 32-bit-Treiber von der IDE bei Erstellen des Connectionstrings über den Objektinspektor angezeigt wird, ist das Übernehmen einfach - auch wenn man gedanklich erstmal stolpert, weil der Treiber beim Download 2010 heißt, in der IDE aber mit der Zahl 12 angezeigt wird.
Wenn ich jetzt zur Laufzeit den 64-bit Treiber nutzen möchte, weiß ich doch gar nicht, wie der Connectionstring korrekt aussehen muss. Weißt du, wie der aussehen sollte? Das wäre natürlich toll.

Gruß
Oswald

[kompi]

Es kommt hier lediglich auf die Bittigkeit des Programms an. Also 64 Bit Programm -> 64 Bit Engine
Gruß Kompi

[OsCor]

Da habe ich mich wohl nicht richtig ausgedrückt: 'Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\XXXXXXX.accdb;Persist Security Info=False'
Das fett Gedruckte ist das, von dem ich nicht weiß, wie es bei der 64-bittigen Version aussehen müsste.

Gruß
Oswald

[kompi]

Das bleibt alles so.
Gruß Kompi

[Delphi.Narium]

Zitat:

Zitat von OsCor (Beitrag 1516255)

Zitat:

Zitat von kompi (Beitrag 1516250)

Welche Komponenten verwendest du?
Ich verwende in meiner Anwendung eine Tadoconnection und nachgeschaltet eine Tadotable.

Genauso mache ich das auch.

Auch eine abgespeckte Engine müsste doch in der Appliste des Systems auftauchen, oder? Da ist bei mir nichts aufgeführt. Welche Engine verwendest denn du?
Außerdem: Wenn ich den 32-bit Treiber verwende, sehe ich ja, wie beim Aufbau des Connection-Strings innerhalb der IDE dieser String aussehen muss. Da muss ich erst mal sehen, wie der 64-bit String aussehen müsste.

@Delphi.Narium
Vermutlich stehe ich ziemlich auf dem Schlauch. Was verbessert sich für mich durch die zusätzliche Funktion?

Gruß
Oswald

Du erstelltst damit aus dem Programm heraus den ConnectionString den das Programm benötigt.

Damit muss Du nicht mehr auf Biegen und Brechen versuchen den ConnectionsString für die 32bittige IDE an ein 64bittiges Programm anzupassen.
Außerdem kannst Du so einfach herausgekommen, ob Du mit 'nem 64bittigen Programm überhaupt einen ConnectionString zusammenstellen kann.

Wenn z. B. Treiber ... für die 64Bit-Version fehlen, wirst Du das hier sofort bemerken.

Sprich: Die Sucherei nach 'nem passenden ConnectionString hat dann innerhalb von ca. 5 Minuten ein Ende.

Hast Du den ConnectionString einmal zusammen, kannst Du die Funktion auf wieder rauswerfen.

Und

Zitat:

Zitat von OsCor

Da muss ich erst mal sehen, wie der 64-bit String aussehen müsste.

musst Du dann nicht mehr. Genau zur Vermeidung dieses Gewusels ist PromptDataSource ja da. Die IDE macht im Objektinspektor doch auch nix anderes. Nur sie macht das für 32 Bit, Du brauchst das aber für 64 Bit. Und das dürften dann am Einfachsten mit 'nem 64 Bit-Programm zu machen sein.

Und wenn Du mit PromptDataSource keinen funktionierenden ConnectionString hinbekommst, dann ist das Problem nicht der ConnectionString sondern "irgendwo" in der Installation der Treiber, Engines, ... zu suchen.

[OsCor]

@Kompi

Ok, alles klar.
Damit man den 64-bit Treiber installieren kann, muss der 32-bittige erstmal deinstalliert werden.
Dann den 64-bittigen installieren und anschließend den 32-bittigen wieder einrichten.

Jetzt funktionierts tatsächlich. Mann…:roll:

@Delphi.Narium

Das habe ich jetzt auch kapiert.

Es dankt herzlich
Oswald

[OsCor]

@Delphi.Narium

Jetzt will ich es aber wissen.
Leider habe ich da noch ein Problem mit deinem Code: ADOConnection.Connected := False; Da wird ADOConnection als undeklarierter Bezeichner angemerkt. Was verstehe ich da falsch?

Gruß
Oswald

[Delphi.Narium]

Die Funktion wird mit

Delphi-Quellcode:

if GetConnectionString(handle,ADOConnection1) then begin

aufgerufen, da musst Du statt ADOConnection1 die von Dir im Programm genutzte TADOConnection übergeben.

Wenn diese tatsächlich undefiniert ist, müsste der Fehler bereits beim Funktionsaufruf passieren.

Es könnte durchaus hilfreich sein, wenn Du mal den Quelltext zeigen könntest, mit dem Du den Aufruf machst, so ist das einfach nur ein Suchen mit Hilfe der :glaskugel:

[OsCor]

Zum Ausprobieren habe ich einfach eine Form erstellt und eine ADOTable und eine ADOConnection drauf gestellt. Wenn ich jetzt deinen Code übernehme, sieht das aus, wie folgt:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}
function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
begin
------> ADOConnection1.Connected := False;  
**// Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
**// analog zu dem Aufbau per ObjektInspektor in der IDE.
**ADOConnection1.ConnectionString := PromptDataSource(handle,sConnection);
**ADOConnection1.Connected := True;
**Result := ADOConnection1.Connected;
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
  if GetConnectionString(handle,ADOConnection1) then begin
****// Hier sollte die Datenbankverbindung bestehen.
****// Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
****// kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
****ShowMessage(ADOConnection1.ConnectionString);
**end
  else
   begin
****MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
**end;
end;

  end;


end.

Die markierte Zeile in der Funktion wird mit „E2003 Undeklarierter Bezeichner” markiert. Was muss ich da noch rein machen?

Gruß
Oswald

[Klaus01]

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
    function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}
function TForm1.GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
begin
------> ADOConnection1.Connected := False;  
**// Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
**// analog zu dem Aufbau per ObjektInspektor in der IDE.
**ADOConnection1.ConnectionString := PromptDataSource(handle,sConnection);
**ADOConnection1.Connected := True;
**Result := ADOConnection1.Connected;
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
  if GetConnectionString(handle,ADOConnection1) then begin
****// Hier sollte die Datenbankverbindung bestehen.
****// Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
****// kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
****ShowMessage(ADOConnection1.ConnectionString);
**end
  else
   begin
****MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
**end;
end;

  end;


end.

Da die Procedure nicht Teil der Klasse TForm ist, kennt sie ADOConnection1 nicht.

Grüße
Klaus

[Delphi.Narium]

Delphi-Quellcode:

function GetConnectionString(handle : THandle; ADOConnection : TADOConnection; sConnection : String = '') : Boolean;
begin
  ADOConnection.Connected := False;
  // Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
  // analog zu dem Aufbau per ObjektInspektor in der IDE.
  ADOConnection.ConnectionString := PromptDataSource(handle,sConnection);
  ADOConnection.Connected := True;
  Result := ADOConnection.Connected;
end;

ADOConnection wird der Funktion doch als Parameter übergeben. Da muss was anderes im Argen liegen, so dass da ein Fehler auftritt. Dabei sollte es vollkommen egal sein, wie die ADOConnection im übrigen Programmteil, im Formular oder sonstwo benannt wurde.

Die Funktion könnte man auch in 'ne beliebige Unit auslagern und dann aus dem Formular aufrufen.

Habe mein Programm, aus dem die Funktion "geklaut" wurde, gerade noch mal kompiliert. Bei meinem ollen Delphi 7 funktioniert das anstandslos.

[OsCor]

Vermutlich ist da ein ganz banaler Fehler, den ich nicht erkennen kann.
Der komplette Code sieht so aus:

Code:

unit HFCon;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Data.DB, Data.Win.ADODB;

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    procedure FormCreate(Sender: TObject);

  private
    function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
  public
  end;

var
  Form1: TForm1;
  implementation

{$R *.dfm}
function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
begin
**ADOConnection1.Connected := False;
**// Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
**// analog zu dem Aufbau per ObjektInspektor in der IDE.
**ADOConnection1.ConnectionString := PromptDataSource(handle, sConnection);
**ADOConnection1.Connected := True;
**Result := ADOConnection1.Connected;
end;
procedure TForm1.FormCreate(Sender: TObject);

begin
  if GetConnectionString(handle,ADOConnection1) then begin
****// Hier sollte die Datenbankverbindung bestehen.
****// Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
****// kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
****ShowMessage(ADOConnection1.ConnectionString);
**end
  else
   begin
****MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
**end;
end;

  end;


end.

In der IDE wird schon in der Deklaration der Funktion der Name GetConnectionString mit einer Wellenlinie unterlegt und als Fehler markiert.

Gruß
Oswald

[johndoe049]

gelöscht - falscher Topic.

[Delphi.Narium]

Zitat:

Zitat von OsCor (Beitrag 1516314)

Vermutlich ist da ein ganz banaler Fehler, den ich nicht erkennen kann.
Der komplette Code sieht so aus:

Code:

unit HFCon;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Data.DB, Data.Win.ADODB;

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    procedure FormCreate(Sender: TObject);

  private
    function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
  public
  end;

var
  Form1: TForm1;
  implementation

{$R *.dfm}
function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;
begin
**ADOConnection1.Connected := False;
**// Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
**// analog zu dem Aufbau per ObjektInspektor in der IDE.
**ADOConnection1.ConnectionString := PromptDataSource(handle, sConnection);
**ADOConnection1.Connected := True;
**Result := ADOConnection1.Connected;
end;
procedure TForm1.FormCreate(Sender: TObject);

begin
  if GetConnectionString(handle,ADOConnection1) then begin
****// Hier sollte die Datenbankverbindung bestehen.
****// Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
****// kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
****ShowMessage(ADOConnection1.ConnectionString);
**end
  else
   begin
****MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
**end;
end;

  end;


end.

In der IDE wird schon in der Deklaration der Funktion der Name GetConnectionString mit einer Wellenlinie unterlegt und als Fehler markiert.

Gruß
Oswald

Die Funktion ist eigentlich kein Teil des Formulars.

Die Zeilen

Delphi-Quellcode:

function GetConnectionString(handle : THandle; ADOConnection1 : TADOConnection;*sConnection : String = '') : Boolean;

hinter

Delphi-Quellcode:

private

ist überflüssig.

Ein Umbenennen von ADOConnection nach ADOConnection1 ist ebenfalls überflüssig.

Einfach mal meine Funktion unverändert übernehmen und den Aufruf ebenfalls?

Noch ein Versuch:

Delphi-Quellcode:

function GetConnectionString(Handle : THandle;
                             ADOConnection : TADOConnection;
                             sConnection : String = '') : Boolean;
begin
  ADOConnection.Connected := False;
  // Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
  // analog zu dem Aufbau per ObjektInspektor in der IDE.
  ADOConnection.ConnectionString := PromptDataSource(handle,sConnection);
  ADOConnection.Connected := True;
  Result := ADOConnection.Connected;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  if GetConnectionString(handle,ADOConnection1) then begin
    // Hier sollte die Datenbankverbindung bestehen.
    // Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
    // kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
    ShowMessage(ADOConnection1.ConnectionString);
  end else begin
    MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
  end;
end;

Und das jetzt bitte einfach nur per Copy&Paste in Deinen Quelltext übernehmen.

[OsCor]

Sei mir bitte nicht böse, aber das hatte ich als allererstes getan und jetzt nochmal. Es macht mich ja gerade fuchsig, dass es bei dir läuft und bei mir nicht.

Wieso wird ADOConnection in der Funktion als undeklarierter Bezeichner angeführt? Nochmal der Quelltext komplett:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Data.DB, Data.Win.ADODB;

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}
function GetConnectionString(Handle : THandle;
*****************************ADOConnection : TADOConnection;
*****************************sConnection : String = '') : Boolean;
begin
**ADOConnection.Connected := False;
**// Hier wird der Dialog zum Aufbau des ConnectionString aufgerufen,
**// analog zu dem Aufbau per ObjektInspektor in der IDE.
**ADOConnection.ConnectionString := PromptDataSource(handle,sConnection);
**ADOConnection.Connected := True;
**Result := ADOConnection.Connected;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  if GetConnectionString(handle,ADOConnection1) then begin
****// Hier sollte die Datenbankverbindung bestehen.
****// Den ConnctionString kannst Du Dir, bei Bedarf per STRG+C aus dem Dialog
****// kopieren und dann an sinnvoller Stelle speichern bzw. der ADOConnection zuweisen.
****ShowMessage(ADOConnection1.ConnectionString);
**end else begin
****MessageDLG('Es konnte keine Datenbankverbindung hergestellt werden.',mtError,[mbOk],0);
**end;
end;

end.

[Delphi.Narium]

Wo kommen die vielen Sterne her, die in der Funktion hier im Quellcode stehen?

Es sieht ein bisserl nach führenden Leerzeichen aus, ein bisserl aber auch nicht.

In Deiner Deklaration des Formulars sind jedoch keine "führenden Sterne" zu sehen.

Haben wir hier irgendein Problem mit nicht zwingend überall darstellbaren Sonderzeichen zu tuen?

Entferne in Deinem Quelltext bitte mal alle Zeichen, die hier im Forum als * dargestellt werden. Bleibt das Problem dann?

[OsCor]

Die Sterne kamen also offensichtlich daher, dass ich den Code einfach per Copy&Paste in meinen Quelltext übernommen habe.
Sternchen sind zwar schön, aber hier waren sie fehl am Platz :-)
Jetzt funktioniert das nämlich. Schön.

Gleich zwei Sachen gelernt…

Vielen Dank sagt
Oswald