Paradox-DB: ständig Index-Fehler

[Ulf346C]

jetzt bin ich aber am verzweifeln...
ich habe ein Warenwirtschaftssystem an zwei Standorten im Einsatz.
Bei dem einen läuft es praktisch störungsfrei, am anderen bekomme ich seit neuestem
ständig Tabellenfehler. Meistens: "Index nicht mehr gültig".
Okay, Paradox ist nicht das perfekte Datenbbanksystem und mittelfristig wird
auch auf SQL umgestellt, aber ich brauche erstmal eine kurzfristige Lösung.

Hat jemand ein ähnliches Problem gehabt und lösen können ?

Umgebung:
Delphi 5 mit BDE
Mix aus dBase- und Paradox-Tabellen
Tabellen liegen auf dem (NT 4.0)-Server
Locking funktioniert (BDE steht auf "Localshare=true")

[mschaefer]

Moin, moin,

also ich denke nicht, dass dies was mit Paradoxtabellen selbst zutun hat. Würde auf ein Hardwareproblem tippen.Entweder läuft der Prozessor an der Taktgrenze oder die Festplatte ist nicht mehr ganz Schreibfehlerfrei.

Grüße // Martin

[franktron]

Das kenn ich ganz einfache lösung guck dir mal das Netzwerk an.

Ich hatte das mal auch bei einem Kunden da hatte der Server ein paar kleine Probs und hatte dauertn die Verbindung zu den Clients gekillt.

[alzaimar]

Bei Paradox stehen in der DB und in den Indextabellen ein Zeitstempel, der identisch sein muss. Wenn Paradox beim öffnen merkt, das diese Zeitstempel ungleich sind, dann denkt es, das da was nich stimmt-> 'Indexfehler'. Das ist zum KOTZEN und NERVIG ohne Ende.

Meine Vorposter haben natürlich Recht, wenn Sie Dir den Tipp geben, das Netzwerk zu schecken, aber der Fehler tritt auch bei lokalen Paradoxprogrammen auf:

Du kannst mal schauen, ob die Anwender dein Programm beenden, oder nur den PC ausschalten, wenn sie nach Hause gehen. Is alles bei mir schon vorgekommen. Es war zum Verzweifeln. Wie gesagt, der Fehler tritt auf, wenn die DB und die IDX-Dateien (oder wie die heissen) nicht zeitgleich gespeichert werden.

Abhilfe gibt es nicht, aber Du kannst ein Reparaturprogramm schreiben, wenn Du die TUTIL32.DLL hast.
Dann gehst Du folgendermassen vor:
1. Lösche die Indexdateien.
2. Lösche die Indexdefinitionen (geht vielleicht nur mit der Datenbankoberfläche)
3. Lösche die Primary Key definitionen (ditto)
4. Lösche die AutoInc-Informationen (ja, siehe oben)
5. Alles in umgekehrter Reihenfolge wieder erstellen (also erst die AutoIncs, dann die Primary....)

Wenn Du eine SW dafür geschrieben hast (kann auch ein Windows-Script sein Dann führst Du das beim Programmstart aus und Du hast Ruhe bis Du alles auf SQL umgeschrieben hast.

Wenn nur ein paar Leute damit arbeiten (<5), dann kannst Du auch Access nehmen. IMHO etwas einfacher in der Umsetzung. Aber, klar: Ne MSDE geht auch: Nur dann müsstest Du auf ADO umschwenken, wenn Du noch mit der BDE rumfrickelst. Das solltest Du aber sowieso...

[franktron]

Zitat von alzaimar:

Dann gehst Du folgendermassen vor:
1. Lösche die Indexdateien.
2. Lösche die Indexdefinitionen (geht vielleicht nur mit der Datenbankoberfläche)
3. Lösche die Primary Key definitionen (ditto)
4. Lösche die AutoInc-Informationen (ja, siehe oben)
5. Alles in umgekehrter Reihenfolge wieder erstellen (also erst die AutoIncs, dann die Primary....)
sowieso...

Ich hab schon gewust warum ich in meine altes Prog sowas gleich fest eingebaut hatte

[alzaimar]

OHHHH, dann wäre das doch mal toll , uns Deinen Code zu posten. Z.b. wie man indizes anlegt, primary keys usw. Das hilft unserem Freund Ulf bestimmt weiter!

[Ulf346C]

tutil32.dll habe ich schon in die Anwendung eingebunden, allerdings als "Wartungsfunktion".
Automatisch aufrufen bem Programmstart geht nicht, weil es sich ja um eine Mehrbenutzerumngebung handelt. Für die Rebuild-Funktion braucht man aber Exclusivzugriff.

*Kopfkratz*

Das mit dem Zeitstempel klingt logisch.

Ich werde die Tabellen wohl wieder auf dBase zurückrüsten. Das ist zwar langsam, stützt aber wenigstens nicht dauernd ab...

[alzaimar]

Wenn Du mit dBase zufrieden bist... Wieso migrierst du nicht einfach auf die MSDE... Man muss ja nicht gleich alle features nutzen?

Zu Deinem Problem mit dem Exklusivzugriff: Du kannst ja bei einem Fehler eine Message an alle Nutzer schicken (per 'mail' broadcast). Die kappen die Verbindung, Du reparierst den Müll, dann eine Mail, das Du fertig bist und fertig...

Zum Thema mail (geht nur bei Domänen, soweit ich weiss):
Der Empfänger erzeugt ein mail-hande, indem er ein 'mailslot' mit irgendeinem Namen (Hier: "Client") erzeugt.

Delphi-Quellcode:

Procedure TMailReceiver.CreateMailSlot;
Begin
  aPath := '\\.\mailslot\Client';
  fHandle := CreateMailSlot(PChar(aPath), 0, MAILSLOT_WAIT_FOREVER, nil);
End;

Offiziel geht der Empfang so: Ich eröffne den mailslot *nicht* mit MAILSLOT_WAIT_FOREVER, sondern mit einem Timeout und schaue dann immer wieder nach, ob was angekommen ist. Die Anzahl der Bytes wird zurückgeliefert. Dann hole ich die Daten ab. Das hat den Vorteil, das ich beliebig lange Nachrichten verschicken kann, aber den Nachteil, das ich eben 'pollen' muss.

Ich mache das Anders: Ich setze mich einfach auf das Handle und vereinbare eine maximale Länge. Sobald was angekommen ist, weiss ich auch, wieviele Bytes die Nachricht enthält...

Delphi-Quellcode:

procedure TMailReceiver.Execute;
Var
  aSize : DWord;

begin
  While Not Terminated Do Begin
    SetLength (fMessage, fMaxLength); // fMessage ist ein privates String-Feld...
    if ReadFile(fHandle, PChar(fMessage)^, fMaxLength, aSize, nil) Then Begin
      If not terminated Then Begin
   SetLength (fMessage, aSize);
        Synchronize (DoOnMailReceived);
        End
    End
end;

Der Sender macht Folgendes:

Delphi-Quellcode:

Procedure SendMail (aComputer, aSlotName, aMessage : String);
var
  Bytes: DWord;
  aPath : String;
  aHandle : THandle;

begin
  If aComputer = '' Then Exit;
  aPath := '\\' + aComputer + '\mailslot\' + aSlotName;
  aHandle := CreateFile(PChar(aPath), GENERIC_WRITE, FILE_SHARE_READ, nil, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);
  try
    if aHandle = INVALID_HANDLE_VALUE then
      If aComputer='*' Then
        SendMail('.',aSlotName, aMessage)
      Else
        Raise EInOutError.CreateFmt('Cannot create mailslot %s\%s',[aComputer,aSlotName])
    else
      If not WriteFile(aHandle, Pointer(aMessage)^, Length(aMessage), Bytes, nil) Then
        If aComputer='*' Then
          SendMail('.',aSlotName, aMessage)
        Else
          Raise EInOutError.CreateFmt('Cannot write to mailslot %s\%s',[aComputer,aSlotName]);
  finally
    if aHandle <> INVALID_HANDLE_VALUE Then
      CloseHandle(aHandle);
    end;
end;

Wenn ich als Computernamen ein '*' übergebe, wird die Nachricht an ALLE Computer in der Domäne verschickt. Um also, an den Computer 'FOO' (der ein mailslot mit Namen 'BAR' erzeugt hat und wartet...) eine Nachricht zu schicken, rufe ich einfach
"Sendmail ('FOO','BAR','Hello foo')" auf. Um eine Nachricht an ALLE Computer zu schicken, benutze ich "Sendmail ('*','BAR','Hello foo')".

Bevor ich hier gepeitscht werde: Es geht auch mit UDP, aber ich habs nunmal mit den mailslots gemacht

[franktron]

Zitat von alzaimar:

OHHHH, dann wäre das doch mal toll , uns Deinen Code zu posten. Z.b. wie man indizes anlegt, primary keys usw. Das hilft unserem Freund Ulf bestimmt weiter!

Das ganz eifach erst alle Indexdatei löschen(auf Dateiebene) mir Deletefile(xxx) und dam mit
TTable.Addindex() wieder hinzufügen

@Ulf346C hast du überhaupt nach dem Post den Cahce von der BDE geleert ??????

[Dummy]

Zitat von Ulf346C:

jetzt bin ich aber am verzweifeln...
ich habe ein Warenwirtschaftssystem an zwei Standorten im Einsatz.
Bei dem einen läuft es praktisch störungsfrei, am anderen bekomme ich seit neuestem
ständig Tabellenfehler. Meistens: "Index nicht mehr gültig".
Okay, Paradox ist nicht das perfekte Datenbbanksystem und mittelfristig wird
auch auf SQL umgestellt, aber ich brauche erstmal eine kurzfristige Lösung.

Hat jemand ein ähnliches Problem gehabt und lösen können ?

Umgebung:
Delphi 5 mit BDE
Mix aus dBase- und Paradox-Tabellen
Tabellen liegen auf dem (NT 4.0)-Server
Locking funktioniert (BDE steht auf "Localshare=true")

Hi Ulf,
arbeite auch noch Paradox weil ich mittlerweile die (meisten) Macken kenne.
Hat deine DB mit dem Indexfehler ein AutoInc-Feld?
Denn die verursachen bei mir den meisten ärger.