ADSDBE: geänderter Feldwert wird nicht angezeigt [ERLEDIGT]

Advantage Database Server

Moderator: Moderatoren

Antworten
DelUser01

ADSDBE: geänderter Feldwert wird nicht angezeigt [ERLEDIGT]

Beitrag von DelUser01 »

Hallo!

Dieses Problem tritt nur mit ADSDBE auf.
Wir setzen ADS 8.10.0.18 auf dem Server ein.

Das Problem:
Unser Prog nutzt eine DBF (hier benannt DBMAIN) zum Datenaustausch zwischen den Progs und zur Speicherung von Zentralwerten.
DBMAIN ist shared (read) geöffnet und wird nur beim Verlassen des Programms geschlossen.
In den Progs wird (z.B.) ein Kalkulationsthread gestartet, der in DBMAIN neue Werte einträgt.
ALle Progs die zu dieser Zeit (auf beliebigen Workstations) laufen zeigen weiterhin die alten Werte aus DBMAIN!
Die geänderten Werte werden nur angezeigt, wenn DBMAIN geschlossen und wieder geöffnet wird oder dbskip(0) verwendet wird.

Info: DBMAIN hat nur einen Record. Alle Progs zeigen auf diesen Record (DBMAIN hat somit keinen index).

Das Prog läuft seit langen Jahren. Das Problem muss sich im Zeitraum eines Jahres eingeschlichen haben.

OHNE ADSDBE - mit purem Xbase++ werden die geänderten Werte sofort in allen anderen Progs angezeigt!

Im ADS Tool werden die geänderten Werte auch angezeigt.

Keine Ahnung wass da mit ADSDBE schief läuft! Hat jemand ähnliches bemerkt bzw. weiß Abhilfe?

MfG,
DelUser01

P.S. Habe gleichen Eintrag in in den Alaska Newsgroups eingestellt.
Zuletzt geändert von DelUser01 am Sa, 20. Feb 2010 15:12, insgesamt 1-mal geändert.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: ADSDBE: geänderter Feldwert wird in PRGs nicht angezeigt

Beitrag von brandelh »

DelUser01 hat geschrieben: OHNE ADSDBE - mit purem Xbase++ werden die geänderten Werte sofort in allen anderen Progs angezeigt!

Im ADS Tool werden die geänderten Werte auch angezeigt.
Hi DelUser01,

sorry, aber das kann nicht sein !

In einem Netzwerk und auch auf einem PC wurde weder von Clipper noch wird von Xbase++ Programmen automatisch im millisekundenbereich der neue Inhalt aus der Festplatte bzw. dem HD-Cache gelesen. Lediglich innerhalb einer Anwendung kann das Programm wissen, dass sich Daten geändert haben.

Aus diesem Grunde führen alle Programme die das brauchen regelmäßig dbSkip(0) aus, oder führen sowieso Satzbewegungen durch, ein normales Skip wirkt genauso. Eventuell nützt es etwas die internen Cache Werte zu ändern, aber externe Änderungen werden nur neu eingelesen wenn

1. Datei geöffnet wird
2. Satzzeiger bewegt oder DBSKIP(0) ausgeführt wird.
Gruß
Hubert
DelUser01

Beitrag von DelUser01 »

Hallo!

>sorry, aber das kann nicht sein
Tja - ich konnte es auch nicht glauben aber es ist reproduzierbar.
Ich habe im Programmstart einen Schalter, der die Verwendung des adsdbe Ein/Ausschaltet.

Eines noch dazugesagt:
das Programm ist sehr umfangreich und was alles passiert bis die neuen Werte aus der DBMAIN angezeigt werden ist sicher nicht in fünf Zeilen erklärt. Es wird kein dbskip(0) ausgeführt. Es ist aber durchaus möglich, dass z.B. ein dbgoto(1) dabei ist.

Aber es führt kein Weg daran vorbei:
Ohne adsdbe zeigen die Programme die neuen Feldwerte - nur mit adsdbe nicht. Das ist der einzige Hinweis auf ein Codeproblem.

MfG,
Roland
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,

eine solche "Ferndiagnose" ist immer schwierig insbesondere wenn
"andere" wohl scheinbar das Problem nicht haben.

Als erstes drängt sich natürlich die Frage nach ein "Downgrade" auf ob
es dann noch läuft ... es muss ja nicht nur ADS sein.

Ich hatte z.b. letzten ein "locking" Problem das ich nicht begriff ... lief das
doch vorher die ganze Zeit. Dazu kam das ich es nicht reproduzieren
konnte und der Fehler nur "ab-und-zu" auftrat. Als ich mir nun das Logfile
genauer ansah entdeckte ich das sich in der Firma wohl jemand ein neues
Notebook angeschaft hatte ... mit VISTA. Das hat nun das ganze Op´s
locking "zerstört" den das SMB2 von VISTA hatte ich nicht eingebunden.

Auch Windows "updates" könnten dran schuld sein das was nicht mehr so
funktioniert wie früher, also unbedingt erstmal eine Gegenprobe mit einem
Backup machen.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Roland Gentner hat geschrieben:Hallo!

>sorry, aber das kann nicht sein
Tja - ich konnte es auch nicht glauben aber es ist reproduzierbar.
Ich habe im Programmstart einen Schalter, der die Verwendung des adsdbe Ein/Ausschaltet.

...
Es wird kein dbskip(0) ausgeführt. Es ist aber durchaus möglich, dass z.B. ein dbgoto(1) dabei ist.
meine Aussage bezog sich auf das automatische Refreshen,
Xbase++ liest nicht automatisch neu ein.

dbgoto(x), dbgotop(), dbgobottom(), dbseek(), dblocate() etc. führen natürlich alle Satzbewegungen durch und verhalten sich wie ein dbskip(0).

Nutzt du eine eigene DBESYS.PRG ?

Wenn ja, bitte mal posten ...
Welche DBE nimmst du für den DBF Teil (FOX oder DBF ?)
Gruß
Hubert
DelUser01

Beitrag von DelUser01 »

Hallo!

Nachfolgend das geänderte DBESYS.PRG
Dazu kommen noch eine Reihe von Funktionen,
welche die Verwendung der richtigen/gewünschten DBE für die
entsprechende Datenbank steuern.

MfG,
Roland
---
Function DbeSys
MainDbeSys()
Return(.T.)
---
Function MainDbeSys
IF !DbeLoad("DBFDBE",.T.)
MainQuit(GsSpTxt( 54 ),GsSpTxt( 54 ),.T.)
ENDIF
IF !DbeLoad("NTXDBE",.T.)
MainQuit(GsSpTxt( 56 ),GsSpTxt( 56 ),.T.)
ENDIF
IF !DbeBuild("DBFNTX","DBFDBE","NTXDBE")
MainQuit(GsSpTxt( 58 ),GsSpTxt( 58 ),.T.)
ENDIF
IF !DbeLoad("DELDBE",.F.)
MainQuit(GsSpTxt( 55 ),GsSpTxt( 55 ),.T.)
ENDIF
IF !DbeLoad("SDFDBE",.F.)
MainQuit(GsSpTxt( 55 ),GsSpTxt( 55 ),.T.)
ENDIF
IF !DbeLoad("ADSDBE",.F.)
MainQuit(GsSpTxt( 53 ),GsSpTxt( 53 ),.T.)
ENDIF
IF !DbeBuild("ADSNTX","ADSDBE","NTXDBE")
MainQuit(GsSpTxt( 57 ),GsSpTxt( 57 ),.T.)
ENDIF
IF !DbeLoad("ODBCDBE",.T.)
MainQuit(GsSpTxt( 127 ),GsSpTxt( 127 ),.T.)
ENDIF
DbeSetDefault("DBFNTX")
Return(.T.)
---
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hi,

wird die DBMAIN.DBF im ADS Falle von der DBFNTX oder der ADSDBE verwaltet ?

Das von mir beschriebene Verhalten (dbGoto(), dbGoTop(), dbGoBottom(), dbseek() etc. liest die Puffer neu ein) bezog sich ausschließlich auf DBFDBE und FOXDBE. Eventuell wird in der ADSDBE mehr gepuffert und nur z.B. dbskip(0) zum erzwungenen Einlesen der Datenänderungen verwendet.

Da jeder Refresh Zeit kostet, wird wohl dort spärlicher auf den SERVER zugegriffen als bei den normalen Dateien.

Verwundert hat mich auch die Zeile:

Code: Alles auswählen

DbeBuild("ADSNTX","ADSDBE","NTXDBE") 
ich kenne mich mit der ADS nicht aus, aber es wundert mich, dass eine lokale Index DBE mit einer SERVER Daten DBE gemischt wird ???

Bei SQL Servern regelt der SERVER die Frage der Indexdateien selbständig.
Gruß
Hubert
DelUser01

Beitrag von DelUser01 »

Hallo!

Wie gesagt, ohne ADS geht es, mit nichtmehr.

Die kurzfristige Lösung war, dbskip(0) vor der Verwendung der Felder aus DBMAIN einzubauen.

Das Problem ist in der Vergangenheit dadurch entstanden, dass die Berechnungsmodule früher lokale Hilfs-DBs verwendet haben und dann die Werte erst zentral abgelegt worden sind. So hat der Ausführende User immer die aktuellen Werte gehabt.
Nach der Umstellung auf unabhängige Berechnungs-Tasks hat die Verfügbarkeit der neu berechneten Werte niemand mehr kontrolliert. Daraus ist das Ganze erst entstanden.

Aber generell ist das schon unschön und unverständlich, dass es ausgerechnet an so einer Stelle einen Unterschied zwischen purem Xbase++ und der Verwendung von ADSDBE gibt.

Also - fürs Erste ist eine Lösung gefunden.

Danke für Eure Unterstützung!
Antworten