SQL (TQuery) und BDE

[Hans Muhl]

Hallo an alle,

habe da ein Problem mit SQL. Wenn ich mit der Komponente TQuery einen einfachen SQL-Befehl ausführen will scheitert das Öffnen der Datenmenge an vereinzelten Rechner. Was kann hier die Ursache sein? Wie gesagt an den meisten Rechner funtzt das ganze, nur vereinzelt scheitert der Befehl xQuery.Open.
Wenn ich für die gleiche Datenbank TTable verwende, kann ich die Datenbank öffnen.

als SQL-Befehl ist nur
SELECT * from xDatenbank
eingetragen.

Fehlt da eine Datei auf dem Rechner?, oder sind die Einstellungen in der BDE falsch?

Wer weiß einen Rat? habe leider auch keine brauchbaren Hinweise im Forum gefunden.

Gruß
Hans

[Bernd Ua]

Hallo,

wie scheitert denn das öffnen ? Über den Database-Error der beim Öffnen wahrscheinlich auftritt, sollten sich doch auch Fehlercode und Kategorie des BDE-Fehlers ermitteln lassen.

Ohne weitere Infos, kann man nur im Trüben stochern

Bern

[Andreas Kosch]

Hallo,

>Fehlt da eine Datei auf dem Rechner?

ich würde zuerst auf die Umgebungsvariblen <b>TEMP</b> und <b>TMP</b> tippen. Im Idealfall sollte diese auf das Verzeichnis <i>C:\Temp</i> oder <i>C:\Tmp</i> verweisen und keine Leerzeichen oder "exotische" Zeichen im Pfadnamen enthalten. Die BDE muss SQL simulieren, indem bei Bedarf temporäre Tabellen erzeugt werden.

Wenn es nicht am Tempverzeichnis liegt, würde ich die Einstellungen der <i>BDE-Administration</i> (alias BDE-Verwaltung) der betroffenen Rechner vergleichen

[Hans Muhl]

Hallo,

>Umgebungsvariblen TEMP und TMP

beziehen sie sich mit den Umgebungsveriabeln auf NetFileDir und PrivatDir der Session? diese wurden auf existierende Verzeichnise gesetzt.
Die BDE-Einstellungen haben wir auch schon, ohne Erfolg, abgeglichen.

Danke Gruß
Han

[Andreas Kosch]

Hallo,

es sind die Windows-Umgebungsvariablen gemeint (die angezeigt werden, wenn man im Fenster der Eingabeaufforderung die Anweisung SET ausführt)

[Hans Muhl]

Hallo,

-> Fehlercode und Kategorie des BDE-Fehlers ermitteln lassen.

habe z.Z. das ganze in Try Except gekapselt, so dass jetzt keine FM erzeugt wird. Sobald ich den die FM habe melde ich mich wieder.

Danke Gru&#223

[Hans Muhl]

Hallo,

-> Windows-Umgebungsvariablen

habe die Veriabeln auf C:\Temp gesetzt, ohne Erfolg.
Habe mir ein kleines Testprogramm geschrieben, dass weiter nichts macht als mit SELECT * FROM xDB eine Datenbank öffnet.
In diesem Testprogramm kann man einstellen ob Session.PrivatDir auf das lokale Verzeichnis gesetzt werden soll. Vor dem Ändern der Umgebungsvariablen ließen sich die Datenbanken nur mit gesetztem PrivatDir öffnen. Nach dem Ändern, immer.

Mit diesem Tool funzt das ganze, in der anderen Anwendung immer noch nicht.

Auf dem Rechner, wo SQL nicht funktioniert, läuft noch eine andere (fremde) Anwendung die die BDE benötigt.

Gruß
Han

[Bernd Ua]

Hi,

Ich bleibe nach wie vor dabei, statt blind
nach Temp-Verzeichnissen zu stochern, einfach mal im Try ..except den Fehler RICHTIG ausgeben

try<BR>
..<BR>
except<BR>
On E: EDBEngineError do<BR>
begin<BR>
// Klassenname ausgeben<BR>
for i:=0 to E.ErrorCount-1 do<BR>
begin<BR>
// Fehlernummern in Errors[i] ausgeben<BR>
end; <BR>
On E:EDatabaseError do<BR>
// Klassenname ausgeben<BR>
// etc pp
end;<BR>

Mit dem Fehlercode der BDE kann man dann hoffentlich was anfangen. In etwas älteren Dokumenten im Borland Developer Network findet sich noch eine Liste dieser Codes mit Beschreibungen. Vielleicht ändert die andere Anwendung ja beim Start auch irgendwas an der Config ?

Bern

[Hans Muhl]

hi,

habe jetzt die Fehlercodes und Meldungen ermitteln lassen:

Fehler 0 = 12289 -> Merkmal nicht verfügbar.

Fehler 1 = 11270 -> Verzeichnis: xy

Fehler 2 = 11270 -> Datei: ..\pdoxUsrs.LCK

Fehler 3 = 11270 -> Verzeichnis: xy

Laut BDE-Fehlercodetabelle steht für den Fehlercode 11270 -> Multiple .NET files in use.

Wie schon erwähnt läuft auf dem gleichen Rechner noch eine fremde Software die auch die BDE nutzt. Verstehe allerdings nicht warum ich eine TTable öffnen kann und TQuery nicht.

Gruß
Han

[Bernd Ua]

Hallo,

komische Kombination von Fehlercodes. Der erste kommt üblicherweise, wen man versucht eine ReuqestLive Query mit serverspezifische Syntax zu machen ( was bei Paradox eh nicht geht) und letztere ... ??? Wie sieht das Query Statement genau aus ? Ist da ein Aliasname mit drin ?

Grüsse Bern

[Hans Muhl]

Hallo,

das Statemant sieht eigentlich immer ganz einfach aus. In einem Fall so:

SELECT * From "xy.DB"

WHERE xyFeldName = 1

ORDER BY xyFeldName

Eigentlich ganz easy. Wie schon erwähnt, in dem einfachen TestProgramm funzt das ganze auch, nur in dem eigentlichen Programm nicht.
Werde mal als nächstes die pas und dfm des Testprogrammes in die Anwendung mit einbinden, um zu checken ob es dann auch noch funktioniert, oder ob das Programm da etwas verbiegt. Melde mich anschließend wieder.

Gruß Han

[Matthias Fichte]

Hallo, setze doch mal in deinem Programm das NetFileDir auf dein Programmverz.<br>
<br>
Session.NetFileDir := ExtractFilePath(Application.Exename);<br>
<br>
Dann löscht du mal alle Pdoxusrs.LCK die du irgendwo finden kannst, und versucht es.<BR>
viel Glück<br>
Gruss Matthia

[Heiko Luettge]

Hallo Matthias,<p>
Tritt das Problem nur auf Rechnern auf, wo das andere Programm installiert ist ?<br>
Vielleicht stimmt ja die Bde-Version nicht, d.dh. das andere Programm hat eine andere Bde-Version installiert.
<p>
Heik

[Hans Muhl]

Hallo,

ich habe SQL auf den besagten Rechner zum laufen gebracht und will nun hier darüber berichten.

Das SQL-Problem ist bei zwei unserer Kunden aufgetreten. Bei beiden lag das Programm auf einem Server und wurde lokal ausgeführt. Bei dem einen Kunden war eine alte BDE mit einem exotischen (thailand oder taiwan) Treiber installiert. Bei dem zweiten Kunden war eine aktuelle BDE auf dem Server installiert.

Nachdem bei beiden eine aktuelle BDE auf den einzelnen Arbeitsplätzen instelliert wurde funktioniert nun auch SQL.

Hat jemand dafür eine Erklärung? mann will ja schließlich nicht dumm in die ewigen Delphi-Jagdgründe eingehen.

Gruß
Han