Tag!
Ich versuche gerade mit Zeos über ado/oledb auf eine Visual FoxPro-Tabelle zuzugreifen.
Die Tabelle "Testtable" ist definiert als:

markieren

Code:

rc_nr numeric 10
text1 char 100
text2 char 100
text3 char 100
text4 char 100
sel numeric 1

Ich verwende eine TZConnection mit protocol ado und eine TZReadOnlyQuery. Die Query dazu ist:

markieren

Code:

SELECT rc_nr,text1,text2,text3,text4,sel FROM Testtable WHERE rc_nr=:rc_nr

Ich aktiviere die TZConnection, setze

markieren

Code:

sql.ParamByName('rc_nr').AsInteger:=5;

und versuche mit sql.Open die Query zu öffnen.
Dann bekomme ich leider die Fehlermeldung: "Ein Objekt, das dem angeforderten Namen oder dem Ordinalverweis entspricht, kann nicht gefunden werden"

Ändere ich die Query wie folgt:

markieren

Code:

SELECT rc_nr,text1,text2,text3,text4,sel FROM Testtable WHERE rc_nr=5

funktioniert alles wie gewünscht.

Jemand einen Tip wo ich da falsch abgebogen bin? Oder muss mit Zeos und/oder VFPOLEDB der Syntax für Parameter anders heissen?

Danke
Luggi

Hallo,

kann es sein, dass Du den Parameter erst in der Eigenschaft "Params" (o. ä.) Deiner Abfrage definieren musst?

Gruß
Frank

Habe ich auch versucht - macht aber keinen Unterschied

Gruß
Luggi

Zitat von FBrust:

kann es sein, dass Du den Parameter erst in der Eigenschaft "Params" (o. ä.) Deiner Abfrage definieren musst?

Dann hätte doch schon ParamByName('rc_nr') fehlschlagen müssen, wenn die Query diesen Parameter nicht automatisch erstellt hätte.

Kann denn die FoxFro DB üverhaupt mit Parametern arbeiten? Was sagen die Docs?

EDIT: Ich mein es gibt so'n paar auserirdische Dbs, welche nur mit "Inline"(Param replace by val) SQL können..

Unter Umständen mußt Du da Klammern.

markieren

Code:

and (wert=:para)

Aber eigentlich sollte ADO damit umgehen können.

Ansonsten schau mal nach dem ADO-Monitor der sollte Dir sagen können was an die DB(?) geschickt wird.

Gruß
K-H

Hallo,
was passiert, wenn Du vor dem ParamByName mal ein Prepare machst?

"numeric 10"
ist mglw eine zu große oder nicht gut implementierte Genauigkeit.

Ich würde einfach mal die Abfrage ändern und einen der Textparameter in der where clause prüfen.
Ggf. den Datentyp probehalber auf Float bzw. das entsprechende Foxpro Pendant setzen
oder schlicht auf Integer.
(Welcher Typ steht original in der TableCreate Anweisung?)
Prüfen, ob der angegebene Typ ein nativer Foxpro Typ ist und ggF. die Deklaration anpassen zu einem nativen.
Die Genauigkeit von 10 auf 4 setzen.

Der Fehler scheint ja eigentlich auszusagen, dass ein unbekanntes Feld /Funktion abgefragt wird. Das könnte wie vermutet eben an Typproblemen liegen.

Auch wenn ich wieder gesteinigt werde:

Wieso noch so ein veraltetes und abgekündigtes DBMS-System wie FoxPro?
Kann man die DB nicht in einem Rutsch auf ein neues DBMS-Format konvertieren und damit arbeiten?

Zitat von EgonHugeist:

Kann denn die FoxFro DB üverhaupt mit Parametern arbeiten? Was sagen die Docs?

Mir war nicht bewusst, daß die Parameter eine Frage der DB sind - ich dachte, daß das der Zugriffs-Layer (in meinem Fall Zeos) erledigt.
So wie's aussieht kann VFPOLEDB keine Parameter.

Zitat von p80286:

Unter Umständen mußt Du da Klammern.

markieren

Code:

and (wert=:para)

Aber eigentlich sollte ADO damit umgehen können.
Ansonsten schau mal nach dem ADO-Monitor der sollte Dir sagen können was an die DB(?) geschickt wird.

Gibts einen ADO-Monitor, der mit ZEOS geht? Der ZEOS Monitor zeigt leider nur die Query mit den Parametern - nicht was er wirklich an den OLE-Treiber übergibt.

Zitat von hoika:

was passiert, wenn Du vor dem ParamByName mal ein Prepare machst?

gleiches Problem...

Zitat von jobo:

"numeric 10"
ist mglw eine zu große oder nicht gut implementierte Genauigkeit.

Die aber nicht von mir stammt. Die Tabellen sind wie sie sind - ich muss sie so nehmen.

Zitat von jobo:

Ich würde einfach mal die Abfrage ändern und einen der Textparameter in der where clause prüfen.

Auch versucht, gleiches Problem.

Zitat von Bernhard Geyer:

Auch wenn ich wieder gesteinigt werde:
Wieso noch so ein veraltetes und abgekündigtes DBMS-System wie FoxPro?
Kann man die DB nicht in einem Rutsch auf ein neues DBMS-Format konvertieren und damit arbeiten?

Ich möchte ja keinen Stein werfen
Aber schon mal dran gedacht, daß es Situationen gibt in denen man nehmen muss was da ist und nicht anders kann?
Ich muss hier Daten aus einem bestehenden System auslesen ohne die Kompatibiltät zu diesem System zu gefährden. Daher VFPOLEDB und nicht tDBF oder sowas und schon gar nicht portieren auf eine andere DB.
Dazu kommt, daß der Aufwand in Grenzen bleiben soll, weil das wahrscheinlich keine Lösung für die Ewigkeit sein wird...

Danke an alle für's mitdenken und antworten - aber ich fürchte EgonHugeist hat recht und das Problem liegt in VFPOLEDB, das keine Paramter kann.

Ich werde also einen Wrapper schreiben in dem ich die Parameter einfach selber im SQL-String austausche... Da ich nur wenige Datentypen brauche ist das wahrscheinlich die eleganteste Lösung...

Gruß
Luggi