Inoffizielles deutsches Xbase-Forum

Ich versuche gerade, in einem DD alle dbf zu löschen inkl. der dazugehörigen fpt und cdx. Also alle aus dem dd entfernt, und dann im Explorer löschen. Bei den allermeisten hat das auch geklappt. Aber gut ein Dutzend will einfach nicht. Der Explorer behauptet, die wären noch vom ADS im Zugriff, könne die nicht löschen.

Aber da greift niemand drauf zu. Und im DD sind die auch weg, also kann auch der ADS nicht mehr. Ich hab mehr als 10 Minuten gewartet, dann sollte auch der hartnäckigste Cache das alles gemerkt haben. Aber nein, es geht nicht.

Wie bekomme ich vom ADS exklusiv gesperrte dbf überhaupt wieder frei? Kann man die irgendwie "abschießen"?

Jan

Ich hab jetzt sogar das DD gelöscht. Der Explorer behauptet weiterhin, der ADS hätte die geöffnet.

Jan

Jetzt versuche ich herauszufinden, wer genau im ADS diese Tabellen sperrt. Also im ARC auf Tools, Remote Server Info mal nachsehen. Mit dem speziellen DD verbinden - es gibt drei auf dem ADS, bzw. jetzt ja eigentlich nur noch 2, da ich eines gelöscht habe.

Und was steht da? Alle dbf, in allen DD. Warum bitte schon wähle ich denn aus der Dropdown-List den betreffenden aus und connecte mich auf den? Warum steht der überhaupt noch dirn, wenn der doch gelöscht ist???

Da stimmt doch irgendwas nicht ...

Jan

Hallo Jan,

wenn da "irgend etwas" durcheinander gekommen ist, lohnt es sich immer das DD zu schließen und gegebenenfalls neu zu öffnen.
-
Je nachdem lohnt es sich auch sich die vom ADS geöffneten Connections und Tabellen (mit Hilfe des ARC) anzuschauen.

Uli

Hallo Uli,

das hatte ja eben leider nichts gebracht. Ich hatte das DD sogar gelöscht, und die dbf sind immer noch vom ADS gesperrt gewesen.

Jan

ADS auch mal neu gestartet?

Manfred,

Der Scherz war gut! Es ging in diesem Fall "nur" um das Entwicklungs-DD, das einfach ein paar wenige dbf und cdx nicht freigeben woltle. Das produktive DD mußte ja weiterlaufen. Ansonsten hätte ich einfach nur mal schnell den Dienst beendet und neu gestartet. Geht aber schlecht, wenn da gerade 20 Leute am Daten einhacken snid ...

Jan

tja, dann wird das Knöchelchenwerfen wohl die einzige Hilfe sein....

*grins* Wenn das nur nicht so traurig wäre. Das hat gestern den ganzen Laden aufgehalten.

Jan

Jan hat geschrieben:Hallo Uli,
das hatte ja eben leider nichts gebracht. Ich hatte das DD sogar gelöscht, und die dbf sind immer noch vom ADS gesperrt gewesen.
Jan

Das heißt, Du hast im ARC gesehen, dass die Tabellen vom ADS geöffnet sind?
Dann siehst Du auch von welchem User und Connection die Tabellen geöffnet sind und kannst die Connections schließen.

Uli

Uli,

das hab ich dann auch irgendwann herausbekommen (der ARC ist nicht so mein tägliches Werkzeug, was nicht immer wieder benutzt wird ist mir deswegen nicht so geläufig).

Stellt sich natürlich immer noch die Frage: Warum das Problem? Schrittweise habe ich alles das hier durchgeführt bzw. kontrolliert:

• Es war kein User mehr auf den Datenbanken
• Alle dbf waren über den ARC manuell aus dem DD gelöscht worden
• Warten für ca. 1/2 Stunde - das sollte kein Cache auf dem Server überleben
  [*}Alle Connections auf dieses DD waren gelöscht
• Das DD war gelöscht
• Ich habe über den ARC nur EINE gesperrte dbf in diesem DD gesehen- nicht die ca. 15, die lt. Explorer vom ADS gesperrt waren. Nach dem Löchen dieser einen Sperre konnten aber alle dbf gelöscht werden

Trotzdem waren von ca. 160 dbf noch 15 inkl. der dazugehörigen fpt und cdx vom ADS gesperrt. Wie kann das sein?

Jan

Jan,

freut mich, dass ich Dir hätte helfen können, wenn meine Nachricht rechtzeitig geschrieben worden wäre und Du diese dann auch rechtzeitig gelesen hättest .
Aus Optimierungsgründen läßt der ADS manchmal Tabellen offen. Vielleicht hat es damit zusammengehangen. Mit Hilfe von CloseCachedTables kann man diese schliessen (es gibt bestimmt auch ein entsprechendes SQL-Statement, habe aber heute keine Zeit, es rauszusuchen).
.
Des weiteren ist es besser, wenn Du die Tabellen über den ARC mittels Drop Table löscht. Schließlich soll normalerweise ja ausschließlich der ADS auf die Tabellen zugreifen .

Hallo Uli,

wenn ich mal etwas Zeit bekomme von meinem Kunden, dann baue ich eine entsprechende Funktion dazu. Also alle dbf droppen (die Funktion mit der entsprechenden SQL-Anweisung hab ich schon im Einsatz), alle dbf, fpt, und cdx auf dem Storage löschen, ein ads-Backup der Dateien im produktiven DD fahren, diese Dateien in das Entwicklungs-DD kopieren, diese dbf in das Entwicklungs-DD einbauen.

Das kann aber natürlich nur funktionieren, wenn das Drop nicht wegen irgendwelcher Phantom-Sperren behindert. Aber ich glaube es gibt auch eine Möglichkeit, diese Sperren per SQL-Anweisungdurchzuführen.

Jan