Moin, moin,

weiß irgendjemand, ob und wie man ein SQL-Script formulieren muss, um bei einer SQL-Abfrage via ADO-Komponente, Verbindung via ODBC, auf eine EXCEL-Tabelle zugreifen zu können? Das von mir verwendete Script arbeitet mit Access einwandfrei (allerdings JET4).

Das SQL Script:

SELECT [Standbeschriftung.ID] AS ID, [Standbeschriftung.AdressSortierung] AS AdressSortierung, [Standbeschriftung.Halle] AS Halle, [Standbeschriftung.StandNr] AS StandNr, [Standbeschriftung.Blendentext] AS Blendentext, [Standbeschriftung.Firmensitz] AS Firmensitz, [Standbeschriftung.Standleistung] AS Standleistung, [Standbeschriftung.OAS] AS OAS
FROM [Standbeschriftung]
WHERE
Standbeschriftung.Halle LIKE :Halle

Verwende ich ein Wildcard-String z.B. '%1%' oder ähnlich anstelle des Parameters :Halle, mault die ADO-Komponente nicht bei der Abfrage der EXCEL-Tabelle.

Und sonst erscheint immer die fiese Fehlermeldung:
Ein Parameterobjekt ist nicht ordnungsgemäß definiert. Inkonsistente oder unvollständige Informationen wurden angegeben.
Und das passiert, nachdem das SQL-Script an die Komponente übergeben und ExecSQL ausgeführt wurde.

Muss oder kann man im Vorwege die Params vorbereiten um z.B. den DataType vorzugeben? Bzw. welchen DataType muss ich für die Excel-Tabelle ansetzen? Oder wie, oder was, oder geht das mit der Paramterübergabe mit Excel nicht.

Help, help, please...

Auf Excel über ADO und ODBC? Komplizierter geht nicht mehr?

Wenn schon dann über ADO und der JET-Engine "direkt" drauf. Dürfte weniger Probleme verursachen als den Umwegü ber ODBC zu gehen.

Würde ich ja gerne machen. Aber wie kann ich das mit den Ado-Komponenten einstellen?

Über Jet 4.0 OLE kann ich nur Access-DB ansprechen...

Passenden Connectionstring aufbauen: http://www.connectionstrings.com/excel/

Das hilft mir leider nicht weiter.

Es lässt sich ja eine Verbindung zu Excel aufbauen. Das löst aber immer noch nicht das Problem...

Die Ado Komponente meckert, weil sie den Parameter :Halle nicht auflösen kann. Diese Parameter muss man bei geschlossener Query zunächst einmal setzen.
Ich gehe dabei folgendermaßen vor:

zusammenfalten · markieren

Delphi-Quellcode:

var
  param : Tparameter;
begin
  with abfrage do begin
    Close;
    SQL.clear;
    SQL.add(sqlstring);
    param := Parameters.Parambyname('Halle');
    param.Datatype := ftstring;
    param.value := 'Die Halle';
    execsql;
  end;
end;

Anschließend sollte Adoquery nicht mehr meckern.

Im übrigen ist dein SQL String etwas lang geraten. Es reicht völlig die folgende Abfrage:

Select ID, AdressSortierung,...
from Standbeschriftung
where Halle like :Halle;

Ich würde jedoch den Parameter :Halle durch einen anderen Ausdruck ersetzen. Es könnte sein, dass die Komponente durch die zweimalige Verwendung desselben Wortes etwas durcheinander kommt.

Gruß Kompi

Zitat von kompi:

Die Ado Komponente meckert, weil sie den Parameter :Halle nicht auflösen kann. Diese Parameter muss man bei geschlossener Query zunächst einmal setzen.
...

Hallo Kompi,

erst mal vielen Dank für deine Antwort. Ist nachvollziehbar, was du geschrieben hast. Ahnte ich ja schon.
Leider muss ich mir dann allerdings für meinen Bedarf programmiertechnisch etwas ausdenken, um den Datentyp vorher herauszubekommen. Sprich: SQL-Script vom Programm analysieren lassen und dann die ermittelten Daten an die Query-Komponente übergeben.
Danach erst SQLExec....

Dann wird ich mal loslegen...

SQLExec? Ein Query.Open wäre hier wohl richtiger?

Gruß
K-H

Zitat von humbuck:

Sprich: SQL-Script vom Programm analysieren lassen und dann die ermittelten Daten an die Query-Komponente übergeben.

Woher bekommst Du den die Query-Anweisung? Wenn das dynamisch zusammengebaut ist, weiss der Zusammenbauer ja, was für ein Datentyp der Parameter haben muss.

Zitat von p80286:

SQLExec? Ein Query.Open wäre hier wohl richtiger?

Hmmm... Wohl kaum. Erst SQLExec und danach Open... Das ist die Reihenfolge.

Zitat von Dejan Vu:

Woher bekommst Du den die Query-Anweisung? Wenn das dynamisch zusammengebaut ist, weiss der Zusammenbauer ja, was für ein Datentyp der Parameter haben muss.

Der 'Zusammenbauer' weiß das vielleicht... . Der brauch dann aber kein Script mit Parameterübergabe. Das brauch nur der, der es nicht weiß. Und der darf dann nicht im Script rumpfuschen.
Ergo: Das Programm muss das dann wissen. Und das klappt jetzt. War ein bissel getippe, um alle möglichen Variationen eines SQL-Scriptes zu berücksichtigen... aber...

funzt!