![]() |
Datenbank: Dbase/Clipper • Version: IV • Zugriff über: ODBC/BDE
dBase/ODBC kann Datensatz nach Änderung nicht schreiben
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 ( :mrgreen: ). 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:
Hier kann es geschehen, daß bereits beim ersten "POST" die Meldung kommt,
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; 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:
Hat irgendjemand eine rettende Idee?
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; Danke Hanns |
Re: dBase/ODBC kann Datensatz nach Änderung nicht schreiben
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] |
Re: dBase/ODBC kann Datensatz nach Änderung nicht schreiben
Zitat:
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 |
Re: dBase/ODBC kann Datensatz nach Änderung nicht schreiben
Zitat:
![]() |
Re: dBase/ODBC kann Datensatz nach Änderung nicht schreiben
Hallo,
eventuell kann auch ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz