dBase/ODBC kann Datensatz nach Änderung nicht schreiben

[HannsW]

Ich muss die Artikel aus dBase/Clipper ausdrucken.
Da ich keinen ODBC-Treiber gefunden habe, der .ntx Indizes unterstützt,
gehe ich die gesamte Datenbank Satz für Satz durch ( ).
Wenn diese Artikel noch nicht in einer Rechnung gedruckt wurden,
setze ich boolean "neueRechung" auf true, und versuche, nach Ausdruck
des aktuellen Artikels, diesen mit neuer Rg_Nummer und - Datum u versehen,
und zu "Posten"

Delphi-Quellcode:

      tableAufPos.First;
      while not tableAufPos.Eof do
      begin
          if tableAufPos.FieldByName('AUFTR_NR').AsString = auftrNr then
            begin
                // Drucke den Artikel 
                // neue Rechnung ?
               if neueRechnung and not istTestDruck then begin
                  tableAufPos.edit;
                  tableAufPos.FieldByName('RECH_NR').AsString
                                        :=  tfRechnNr.Text;
                  tableAufPos.FieldByName('RECH_DAT').AsString
                                         :=  tfRechDatum.Text;
                  tableAufPos.Post;
                end; 
            end;
            { Ende einzelner Artikel }
            tableAufPos.Next;
       end;

Hier kann es geschehen, daß bereits beim ersten "POST" die Meldung kommt,
daß ein anderer Prozess auf die daten zugreift.

Für Aufpos habe ich ein tabelAUfPos und ein dsAUfpos verknüpft.

nachfolgender Code hingegen klappt immer:

Delphi-Quellcode:

function TRgDruckForm.incNummer ( nummernTyp: String): boolean;
var
suchen,found: boolean;
neueNummer  : double;
begin
      tableNummern.Active := true;
      tableNummern.FindFirst;
      suchen := true;
      found := false;
       while suchen do
       begin
          if tableNummern.FieldByName('NUMMERNART').AsString = nummernTyp then
            begin
            suchen := false;
            found := true;
            neueNummer := tableNummern.FieldByName('NUMMER').AsFloat +1.0;
            tableNummern.edit;
            tableNummern.Fields[1].AsFloat :=  neueNummer;
            tableNummern.Post;
            end
          else
             suchen := tableNummern.FindNext;
       end;
     if found then
        Result := true
     else
        Result := false;

     tableNummern.Active := false;

end;

Hat irgendjemand eine rettende Idee?
Danke Hanns

[nahpets]

Hallo,

richtig helfen kann ich nicht, aber:

Die erste Fehlermeldung kenne ich z. B. aus dieser Situation:

Ein Programm greift über die BDE auf eine Tabelle zu, es tritt ein Fehler auf, das Programm wird abgebrochen. Der nächste Versuch, auf den Datensatz zuzugreifen scheitert, und zwar solange, bis man alle Programme, die die BDE nutzen, beendet. Danach ist der Spuk vorbei, bis man wieder in eine Fehlersituation gerät. Deshalb dieses: Manchmal geht es, manchmal geht es nicht. Zu den Programmen, die die BDE nutzen, gehört in diesem Falle auch die IDE, die man ebenfalls beenden muss, damit alle DLL's der BDE freigegeben werden.
Aus diesem Grund habe ich mir angewöhnt: Wenn die BDE im Einsatz ist, das Öffnen von Abfragen und/oder Tabellen nicht über den Objektinspektor zu machen, sondern erst zur Laufzeit im FormCreate o. ä.. Hierdurch lassen sich Konflikte zwischen Zugriffen der Entwicklungsumgebung und Programm auf die Datenbank vermeiden.

Eine weitere mögliche Fehlerursache könnte die PDOXUSRS.NET sein. Wenn es davon mehrere auf einem Rechner gibt, kann das zu derartigen Fehlern führen, vor allem beim Mehrbenutzerbetrieb.
[edit]hat (wie üblich) Schreibfehler gefunden[/edit]

[HannsW]

Zitat von nahpets:

Hallo,

richtig helfen kann ich nicht, aber:

Herzlichen Dank, Dein Beitrag hat mir immerhin gezeigt, daß es da so ein paar kleine
Problemchen gibt.

Ich habe mal vor langer Zeit eine dBase-Klasse geschrieben, die Funktionen zum Lesen etc hat.
( damals mussten dBase-Dateien in ein neues DS eingelesen werdn.

Da ich ohnehin nicht auf INdexe zu greifen kann ( NTX statt ndx) werde ich wohl das SChreiben
in "DBF"-Dateien über meine alte Klasse machen müssen. Da wird dann halt auch sequentiell
die Datei abgehandelt, aber beim Tempo der hueigen Rechner sollte dies reichen.

Danke nochmals für den Hinweis auf die "Unsicherheit ODBC/BDE"

Hanns

[joachimd]

Zitat von HannsW:

Da ich ohnehin nicht auf INdexe zu greifen kann ( NTX statt ndx) werde ich wohl das SChreiben
in "DBF"-Dateien über meine alte Klasse machen müssen. Da wird dann halt auch sequentiell
die Datei abgehandelt, aber beim Tempo der hueigen Rechner sollte dies reichen.

Advantage kann DBF/NTX direkt verarbeiten und braucht keine BDE. Komponenten und Local Server sind kostenfrei.

[nahpets]

Hallo,

eventuell kann auch TDBF helfen. Freewarekomponente von Sourceforge, kann auch mit diversen Indexvarianten umgehen, habe aber noch nicht herausgefunden, mit welchen Indextypen und vor allem: wie zuverlässig. Normaler Umgang mit dBase funktioniert aber problemlos.