Hallo,
seit relativ kurzer Zeit haben wir beim Kunden das Problem, das manche Daten erst verzögert gespeichert werden. Die Daten liegen als FOXCDX im proprietären Zugriff des ADS 12.1. Das Ganze macht sich so bemerkbar, das z. B. im Programm ein Datum erfasst wird, der Satz wird gespeichert, die Daten sind bei Abruf im Programm aber erst zwei oder drei Stunden später sichtbar.
Mich irritiert, da das anscheinend selektiv auf Datumswerte geht. Und die Verzögerung so lang ist. Das kann ja ansich nichts mehr mit SMB zu tun haben. Erst Recht nicht beim ADS.
Jan
ADS - Verzögerungen beim Speichern
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
ADS - Verzögerungen beim Speichern
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: ADS - Verzögerungen beim Speichern
Ich lege ein mittelwichtiges Körperteil dafür ins Feuer, dass dieses Problem hausgemacht ist. Irgendein Cache, der zwei Stunden lang nicht aktualisiert wird? Das gab's vielleicht im Lochkartenzeitalter. Du suchst oder vergleichst falsch, Jan.
Herzlich,
Tom
Tom
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: ADS - Verzögerungen beim Speichern
Tom,
was auch immer gerade bei Dir ein "mittelwichtiges Körperteil" wäre. Mich würde interessieren was Du bereit wärst, dafür zu opfern .
Aber zum Thema: Klar drängt der Verdacht sich auf. Trifft aber hier nicht zu. Es ist das ganz normale Fakturiermodul. Keine Sonderfunktion. Da werden jeden Tag tausende von Daten erfasst, die alle auch immer sofort in einer Statusübersicht sichtbar sind. Nur dieses blöde Datum nicht. Es wird auch historisch bedingt immer direkt in die Tabelle geschrieben, und ich habe nach ein paar bösen Erfahrungen in der Vergangenheit eine kurze Funktion, die sicherstellt, das die erfassten Daten wirklich zurückgeschrieben werden. Das funktioniert auch alles einwandfrei. Nur nicht bei diesem Datum, das im gleichen Datensatz steht wie all die anderen Daten zu dieser Fakturier-Position. Normalisierung wird da nicht sonderlich groß geschrieben.
Der ADS dient auch nur als Datengrab. Da gibt es keinerlei Trigger, stored Procedures, oder sonstwas. Und der ist auf proprietären Zugriff eingestellt, da sollte also von extern niemand dazwischen pfuschen können.
Ich werd aber mal die Sachbearbeiter interviewen. Wer weiß, vielleicht haben die einen Sonderweg gefunden, die Daten dort einzuhacken. Und hebeln damit die üblichen Funktionalitäten aus. Das Leben wäre so einfach, wenn es nur nicht immer diese Kunden und die Anwender gäbe ...
Jan
was auch immer gerade bei Dir ein "mittelwichtiges Körperteil" wäre. Mich würde interessieren was Du bereit wärst, dafür zu opfern .
Aber zum Thema: Klar drängt der Verdacht sich auf. Trifft aber hier nicht zu. Es ist das ganz normale Fakturiermodul. Keine Sonderfunktion. Da werden jeden Tag tausende von Daten erfasst, die alle auch immer sofort in einer Statusübersicht sichtbar sind. Nur dieses blöde Datum nicht. Es wird auch historisch bedingt immer direkt in die Tabelle geschrieben, und ich habe nach ein paar bösen Erfahrungen in der Vergangenheit eine kurze Funktion, die sicherstellt, das die erfassten Daten wirklich zurückgeschrieben werden. Das funktioniert auch alles einwandfrei. Nur nicht bei diesem Datum, das im gleichen Datensatz steht wie all die anderen Daten zu dieser Fakturier-Position. Normalisierung wird da nicht sonderlich groß geschrieben.
Der ADS dient auch nur als Datengrab. Da gibt es keinerlei Trigger, stored Procedures, oder sonstwas. Und der ist auf proprietären Zugriff eingestellt, da sollte also von extern niemand dazwischen pfuschen können.
Ich werd aber mal die Sachbearbeiter interviewen. Wer weiß, vielleicht haben die einen Sonderweg gefunden, die Daten dort einzuhacken. Und hebeln damit die üblichen Funktionalitäten aus. Das Leben wäre so einfach, wenn es nur nicht immer diese Kunden und die Anwender gäbe ...
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: ADS - Verzögerungen beim Speichern
Hallo, Jan.
Mittelwichtig sind bei Männern Organe wie die Milz oder die Brustwarzen. Es gibt auch ganz viele Leute, die ihr Rückgrat eigentlich nicht brauchen.
Das ist hundertprozentig hausgemacht. Klemm mal ein bisschen Debug-Code rund um die vermeintlich sichere Schreiberei des Datums.
Mittelwichtig sind bei Männern Organe wie die Milz oder die Brustwarzen. Es gibt auch ganz viele Leute, die ihr Rückgrat eigentlich nicht brauchen.
Das ist hundertprozentig hausgemacht. Klemm mal ein bisschen Debug-Code rund um die vermeintlich sichere Schreiberei des Datums.
Herzlich,
Tom
Tom
- BJelinek
- Rekursionen-Architekt
- Beiträge: 218
- Registriert: Sa, 02. Jun 2012 20:57
- Wohnort: 73257 Köngen
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 3 Mal
Re: ADS - Verzögerungen beim Speichern
Hallo zusammen.
Könnte es sein, dass das Datumsfeld doppelt in der Datenbank steht.
War bei mir mal der Fall, wie auch immer das Feld dort rein kam.
Könnte es sein, dass das Datumsfeld doppelt in der Datenbank steht.
War bei mir mal der Fall, wie auch immer das Feld dort rein kam.
Grüße
Bernd
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Bernd
Mitglied des Deutschsprachige Xbase-Entwickler e. V.