SQL-Abfrage in Excel-Tabelle via ADO mit Parameter

[humbuck]

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...

[Bernhard Geyer]

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.

[humbuck]

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...:?

[Bernhard Geyer]

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

[humbuck]

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...

[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.
Ich gehe dabei folgendermaßen vor:

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

[humbuck]

Zitat:

Zitat von kompi (Beitrag 1284159)

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...

[p80286]

SQLExec? Ein

Delphi-Quellcode:

Query.Open

wäre hier wohl richtiger?

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von humbuck (Beitrag 1284246)

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.

[humbuck]

Zitat:

Zitat von p80286 (Beitrag 1284253)

SQLExec? Ein

Delphi-Quellcode:

Query.Open

wäre hier wohl richtiger?

:?

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

Zitat:

Zitat von Dejan Vu (Beitrag 1284273)

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. :wink: Und das klappt jetzt. War ein bissel getippe, um alle möglichen Variationen eines SQL-Scriptes zu berücksichtigen... aber...

funzt! :-D

[Sir Rufo]

Zitat:

Zitat von humbuck (Beitrag 1284311)

Zitat:

Zitat von p80286 (Beitrag 1284253)

SQLExec? Ein

Delphi-Quellcode:

Query.Open

wäre hier wohl richtiger?

:?

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

Häh, seit wann denn das?

Open macht exaktemente das absolut gleiche wie ExecSQL mit einem Unterschied, bei Open wird auch eine Datenmenge erwartet, bei ExecSQL eben nicht.

Ein Blick in die Dokumentation ist da wohl fällig
Data.Win.ADODB.TADOQuery.ExecSQL und Data.Win.ADODB.TADOQuery.Open
Schönes Zitat aus der Doku

Zitat:

Anmerkung: Rufen Sie bei SELECT-Anweisungen anstelle von ExecSQL die Methode Open auf, oder setzen Sie die Eigenschaft Active auf true.

PS

Für SQL-Code gibt es auch Code-Tags [ CODE="SQL" ] sieht dann gleich viel hübscher aus

SQL-Code:

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

[humbuck]

Zitat:

Zitat von Sir Rufo (Beitrag 1284327)

Anmerkung: Rufen Sie bei SELECT-Anweisungen anstelle von ExecSQL die Methode Open auf, oder setzen Sie die Eigenschaft Active auf true.

Du hast natürlich Recht. Hierarchisch gesehen gibt es jedoch die besagte Reihenfolge.
Ich benötige aber in meinem Fall keine Datenmenge vom Query. Für mich ist der Aufruf von ExecSQL zunächst nur zur Tabellenstrukturanalyse notwendig, bzw. um auch ggf. eine Exception auszulösen.

Erst im späteren Verlauf des Programms benötige ich eine Datenmenge.

Zitat:

Für SQL-Code gibt es auch Code-Tags [ CODE="SQL" ] sieht dann gleich viel hübscher aus

Das sieht sogar hervorragend aus!:-D

Mein Programm generiert das SQL-Script auf Anforderung. Das sieht dann nicht immer so schick aus, erfüllt aber seinen Zweck.
Von mir war es nur reine Faulheit, das ganze etwas schnuckeliger zu gestalten. Copy und Paste und Tschüß... Sorry:oops:

[Perlsau]

Zitat:

Zitat von Sir Rufo (Beitrag 1284327)

Zitat:

Zitat von humbuck (Beitrag 1284311)

Zitat:

Zitat von p80286 (Beitrag 1284253)

SQLExec? Ein

Delphi-Quellcode:

Query.Open

wäre hier wohl richtiger?

:?

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

Häh, seit wann denn das?

Du, der Mann hat 30 Jahre Erfahrung mit Datenbanken, ich würde seine Aussagen daher nicht anzweifeln :stupid:

[Bernhard Geyer]

Zitat:

Zitat von humbuck (Beitrag 1284330)

Du hast natürlich Recht. Hierarchisch gesehen gibt es jedoch die besagte Reihenfolge.
Ich benötige aber in meinem Fall keine Datenmenge vom Query. Für mich ist der Aufruf von ExecSQL zunächst nur zur Tabellenstrukturanalyse notwendig, bzw. um auch ggf. eine Exception auszulösen.

Komisches Vorgehen:gruebel: Zur Tabellenstrukturanalyse gibt es bessere Möglichkeiten welche dir auch gezeigt wurden. Ein "ich lass es auf eine Excpetion laufen" dürfte auch im Rahmen von Performance nicht die beste sein da solche Exceptions teilweise sehr aufwändig sind.