Inoffizielles deutsches Xbase-Forum

Hallo allerseits,

ich habe ein größeres Problem: Gestern war der Linux-ADS beim Kunden abgestürzt. Seit Neustart und ReIndex läuft der ADS wieder.
Wenn ich aber den ARC aufrufe, das zugehörige Data Dictionary öffne und mir die Eigenschaften einer Tabelle anschauen möchte, kommt die Fehlermeldung

Error 7200: AQE Error: State = HY000; NativeError = 1500; [iAnywhere Solutions][Advantage SQL][ASA] Failed to load Unicode support DLL or Shared Object.

Wenn man die Fehlermeldung bestätigt, öffnet sich anschließend der "Table Designer" aber es wird nur das erste Feld der Tabelle angezeigt.

Woran könnte das liegen?

Uli

die Hilfe gibt dazu folgenden Hinweis:

Check ads_err.adt and ads_err.dbf for the path where the Advantage is trying load the DLL or shared object.

Prüfe, ob diese Datei dort vorhanden ist.

nightcrawler hat geschrieben:die Hilfe gibt dazu folgenden Hinweis:

Check ads_err.adt and ads_err.dbf for the path where the Advantage is trying load the DLL or shared object.

Prüfe, ob diese Datei dort vorhanden ist.

Ich bin mir nicht sicher, ob ich verstehe, was Du meinst.
Die ads_err.adt habe ich geprüft. Sie ist vorhanden und enthält eine für mich nichts sagende Fehlermeldung bezüglich des Fehlers 1500. Unter Filename steht entweder nichts oder

F1=239582

Weitere Felder: Ads_Source=aof.c
ADS_Ver = 10.10.0.6

Uli

EDIT: in der ads_err.dbf ist der jüngste Eintrag vom 09.12.2013 und hat sicher nichts mit dem aktuellen Problem zu tun.

Noch eine Fehlermeldung: wenn ich eine Tabelle im ARC geöffnet habe und einen Filter eingebe, kommt die Fehlermeldung

BrowseTable: Error 1500: Failed to load Unicode support DLL or Shared Object.

Unicode-Felder habe ich definitiv nicht im Einsatz.

Uli

ARC ist in Delphi geschrieben, Delphi macht in den letzten Versionen nur noch Unicode...daher braucht der ARC Unicode, auch wenn keine Unicode Felder im Einsatz sind. Im ARC-Verzeichnis sollten sich die aicu32.dll und eine icudt40l.dat befinden. Am Server die libaicu.so und die zugehörige icudt40l.dat.

nightcrawler hat geschrieben:ARC ist in Delphi geschrieben, Delphi macht in den letzten Versionen nur noch Unicode...daher braucht der ARC Unicode, auch wenn keine Unicode Felder im Einsatz sind. Im ARC-Verzeichnis sollten sich die aicu32.dll und eine icudt40l.dat befinden. Am Server die libaicu.so und die zugehörige icudt40l.dat.

Alle Dateien sind (weiterhin) vorhanden.
Die Ursache muss eine andere sein!

Uli

Heute war bereits der 2. Absturz der Woche. Ich habe daraufhin eine Sicherung der Datenbank auf meinen Entwicklungsrechner portiert. Dort kommt es glücklicherweise nicht zu den Fehlern. Das heißt, es muß am Linux-ADS oder an der Workstation liegen, mit der ich beim Kunden arbeite (oder durch das Backup/Restore wird der Fehler repariert).

Inzwischen habe ich festgestellt, dass es noch eine aktuellere Version 10.10.0.49 statt der eingesetzten 10.10.0.6 gibt. Ich hatte fälschlicherweise angenommen, dass .6 aktueller als .49 ist . Wenn ich mir die korrigierten Bugfixes anschaue, kann es sehr gut sein, dass diese Version in meinem Fall hoffentlich hilft! Am Montag Abend wird diese Version installiert.
Ich werde dann berichten.

Uli

Am Montag haben wir in einer Hauruck-Aktion die 10.10.0.49 installiert. Seitdem tauchen die Fehler im ARC nicht mehr auf!

Uli

Nachdem seit Montag wieder dieser ominöse Fehler auftauchte, habe ich folgendes herausgefunden.

Am Freitag wurde die Servermaschine, auf der der ADS läuft, gewartet. Dabei wurde vor dem runterfahren der Maschine der ADS mittels "kill" beendet (kann man den ADS unter Linux eigentlich auch runterfahren? ...) .
Vermutlich hat der ADS dabei seine Fehlerdatei ads_err.adt zerstört. Auf jeden Fall fiel mir auf, dass kein Datensatz mehr darin enthalten war und auch keine neuen angelegt wurden. Das Öffnen der Fehlerdatei mittels ARC ging zwar, aber ein Packen funktionierte nicht.
Deshalb wurde heute nochmals der ADS mittels "kill" beendet und neu gestartet. Danach konnte ich mit Hilfe des ARC, die Fehlerdatei öffnen, packen und ein Reindex durchführen. Seitdem läuft der ADS vermutlich wieder einwandfrei .

Uli

P.S. Weis jemand, wann die Version 12 vom ADS herauskommt?

Heute ist mal wieder der ominöse Fehler aufgetaucht.
Sobald die Möglichkeit besteht, werde ich wieder wie am 29.10.2014 mit dem entsprechenden Aufwand vorgehen .
--
Vielleicht gibt es aber noch eine andere Möglichkeit. Die ads_err.dat wird "intern" vom ADS offen gehalten. Kann man den ADS dazu bewegen, die Tabelle zu schließen? Dann könnte ich im laufenden Betrieb ein Pack und ReIndex drüber laufen lassen...

Uli

Die letzten Stunden habe ich mit Versuchen verbracht, die Daten wieder zu reparieren. Leider erfolglos...