#include "ads.ch"
#include "adsdbe.ch"
Function Main
Local oSession
DBELoad("ADSDBE", .F.)
DBESetDefault("ADSDBE")
oSession := dacSession():New( "ADSDBE", "Y:" )
If !oSession:isConnected( )
? "Fehler: "+Str(oSession:getLastError(),4,0)
Endif
Return NIL
Wenn Y: nicht auf ein ADS-Laufwerk zeigt, sollte der Fehler 6420 kommen, es kommt aber seit der Version 2.0 ein Fehler 5381. Und dieser Fehler wird bei allen ADS-Fehlern gemeldet. Kann das jemand reproduzieren, oder hat jemand dafür eine Lösung?
Gruß Matthias
Hallo,
das Problem ist nicht der einzelne Fehler, sondern dass alle Fehler die gleiche falsche Fehlernummer ausgeben
und man keine Hilfe bei der Fehlersuche mehr hat.
Gruß Matthias
vielleicht basieren alle Fehler ja wirklich auf einer zentralen Ursache?
Z.B. unbekannter uerbindungsabbruch zum ADS-Server oder so.
Da könnte mit der richtigen ADS.INI schon was korrigiert werden.
Hast Du eine ADS.INI?
Was steht in der ADS_ERR.DBF?
Verwendest Du die DLLs aus dem ADS-Verzeichnis (ace32.dll, axcws32.dll)?
In welcher ADS-Version passiert das?
Zuletzt geändert von DelUser01 am Mo, 06. Nov 2017 18:20, insgesamt 1-mal geändert.
Hi,
das Problem ist wirklich nicht der einzelne Fehler. Wenn ich mein Beispiel mit dem 1.9 kompiliere liefert es einen 6420 Fehler.
Wir haben ca. 1000 Anwendersysteme, davon viele mit ADS. Alle melden nur noch Fehler 5381 an unsere Hotline .....
Vielleicht ist es nicht verständlich gewesen. Das Beispiel soll einen Fehler produzieren. Auf einem 1.9 System der zu erwartende 6420, aber auf einem 2.0 System leider einen 5381, der kein gültiger ADS-Fehler ist.
Ich suche also eine Lösung, dass :GetLastError() wieder gültige ADS-Meldungen ausgibt. (Und damit unsere Fehlerbehandlung wieder funktioniert)
Danke und Gruß Matthias
ich hatte das selbe auch mal, durch korrekten "Connect-String" wie unten konnte ich das Problem lösen. Bitte überprüfe auch dein Laufwerkmapping, ohne dass der angegebene Pfad auch tatsächlich "gültig" gemappt ist ( z.B. auf M:) ist ein Connect nicht möglich. ( \ = Backslash verwenden)
Hallo Zusammen,
ich scheine mich sehr schlecht auszudrücken. In meinem Bespiel muss ich nur den Server wieder starten und der Fehler ist weg.
Meine Frage war, ob jemand reproduzieren kann, dass in xBase 2.0 alle Fehler vom ADS nur noch 5381 lauten. Deswegen ein
einfaches Beispiel, das auch ohne ADS funktioniert (Also einen Fehler liefert!).
Gruß Matthias
soweit OK.
Meine Frage: bist Du mit allen betieligten Parts auf dem aktuelen Stand oder hast Du nur nur auf v2 aktualisiert?
Es schein doch an Deiner Umgebung zu liegen dass Du und Deine Kunden das Problem haben. Sonst hätte sich doch möglicher Weise jemand gemeldet.
Das sollte es aber. Entweder hast Du einen ADS (Oder ADS local) auf dem Laufwerk Y: laufen, oder Du hast ein ganz anderes Problem. Mir geht darum zu erfahren, ,ob es andere gibt, die keine normalen Fehler vom ADS sondern nur noch 5381 bekommen.
hast du die passenden Firewallregeln (in/out) auf Server und Arbitsplatz? Hast du mal versucht diese zu löschen und neu zu erstellen. Evtl. hast du ein "Firewallproblem"
Es gäbe noch eine andere Ursache: Alaska liefert zu alte ADS DLL's aus. Dies könnte die Ursache sein.
Ersetzte ACE32.DLL, AXCWS32.DLL, ADSLOC32.DLL mit den aktuellen zu deiner ADS-Server Version passenden.
ramses hat geschrieben: ↑So, 12. Nov 2017 21:50Alaska liefert zu alte ADS DLL's aus. Dies könnte die Ursache sein. Ersetzte ACE32.DLL, AXCWS32.DLL, ADSLOC32.DLL mit den aktuellen zu deiner ADS-Server Version passenden.
Hatte ich Matthias auch schon gesagt, er macht dazu aber keine Angaben...
Kommt schon
Also wir haben alle DLLs (ACExxx und co) mit den verschiedenen ADS-Varianten durchgetestet. Immer das gleiche Ergebnis. 1.9 verhält sich normal, 2.0 liefert 5381. Wir sind uns deswegen relativ sicher, dass der ADS nicht die Ursache ist.
Mal sehen was aus dem PDR wird. Meine Frage, ob auch bei Euch eine falsche Fehlernummer kommt, ist erst mal beantwortet.
nachdem Du nur ab- und zu etwas zu Deiner Umgebung rausrückst ist noch immer unklar:
- In welcher/welchen ADS-Version(en) passiert das?
- Hast Du eine ADS.INI? Was steht drin?
- Was steht in der ADS_ERR.DBF zu dem Fehler?
Das Aktualisieren/Wechseln der DLLs bringt möglicher Weise nur was wenn Du auch einen aktuellen ADS verwendest. Möchtest Du eventuell nur vermeiden den Kunden mitzuteilen, dass "die" mit Deinem Programmupdate (1.9->2.0) nun auch den ADS aktualisiern (kaufen) müssen?
Wir möchten eigentlich nur wieder anhand der Fehlermeldungen feststellen, was einen Fehler auslöst ohne raten zu müssen. Ansonsten laufen die Anlagen mit ADS und xbase 2.0 ohne Probleme.
ich kann mich nur Roland anschliessen: Mit korrektem Connect-String und den aktuellen ADS DLL's läuft ADS mit der 2.0 Xbase einwandfrei.
in unserer ADS.INI steht nur:
[SETTINGS]
RETRY_ADS_CONNECTS=1
MAX_TIMEOUTS=30
Wenn Fehler auftreten haben diese korrekte dokumentierte Nummern.
Jedenfalls mit der ADS Version 10 die wir zur Zeit noch verwenden. Wir wollen ADS vollständig loswerden und wechseln auf PostgresSQL deshalb auch keine neue Version mehr kaufen.....
Versuche doch mal OHNE deine INI. Meiner Meinung nach ist diese nicht korrekt.
Gruss Carlo
Zuletzt geändert von ramses am So, 12. Nov 2017 23:45, insgesamt 1-mal geändert.