Defekte Tabelle erkennbar?

[Sigbert Engelhardt]

Hallo,<br>
Ich habe hier eine Tabelle, bei der bei einigen Records in einigen Feldern nur kryptische Zeichen stehen.<br>
Es sind niemals die gleichen Felder, aber alles Memo's oder Blobs.<br>
Wie und wann das aufgetreten ist, lässt sich leider nicht ermitteln.<br>
Die Tabelle lässt sich aber normal benutzen.<br>
Der ARC meldet bei einer Prüfung auch keinen Fehler.<br>
Das macht mir etwas Angst. Gibt es eine Möglichkeit solche Probleme zu erkennen?<br>
Benutzt wird Version 7.1.<br>
<br>
Sigbert

[Bernhard Geyer]

Vermutlich nicht. Ich denke mal das hat ein Programm mit unpassenden Einstellungen in der verwendeten adslocal.cfg darauf zugegriffen

[Sigbert Engelhardt]

Hallo Bernhard,<br>
Die Charsets stehen richtig.<br>
An einen Eingriff des Kunden glaube ich nicht.<br>
Es sind auch urlalte Datensätze wahllos beschädigt.<br>
Aber nur Blob-Felder.<br>
Sigber

[Bernhard Geyer]

Wie soll die Datenbank erkennen das ein Blob-Feld "beschädigt" ist. Doch nur wenn CRC-Checksummen oder ähnliches gebildet werden. Und ich vermute das ist bei ADS aufgrund von Performanceaspekten nicht der Fall. Wäre mal interessant wie sich hier andere DB's verhalten würden wenn man in den DB-Dateien mittels Hex-Editoren Daten verändern würde.

Als Verursacher würde ich auf die üblichen Verdächtigen wie Firewall oder Virenscanner Tippen. Was solche Programme ab und zu verursachen ..

[Michael Habbe]

Denkbar wäre auch ein Datenzugriff mit einem anderen Charset. Man braucht nur bei der Installation des ARC nicht aufpassen und päng.... Kunden sind da einfallsreich.......
.
Um wieviele Datensätze geht es? Schonmal gezählt

[Sigbert Engelhardt]

Es sind zum Glück nur eine Handvoll.
Das Merkwürdige ist, es handelt sich dabei auch um ein Jahr alte
Datensätze, an die der Kunde eigentlich nicht mehr heran kommt.

Falsche Charset schliesse ich aus

[Michael Koecher]

Hi,
hatte mal ähnliche Effekte.
Probier mal auf den Clients folgenden REG-Code einzufügen:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\LanmanServer\Parameters]
"EnableOpLockForceClose"=dword:00000001
"EnableOpLocks"=dword:00000000
"EnableSharedNetDrives"=dword:00000001
"SharingViolationDelay"=dword:00000000
"SharingViolationRetries"=dword:00000000

cu Michae

[Sigbert Engelhardt]

REG-Code...
Ist aber nur eine lokale Anwendung.
EnableOpLocks kannte ich schon.
Was macht der Rest

[PM Heiko]

Mhhh.. Ähnliche Probleme (kryptische Zeichen in der Datenbank) hatte ich nach dem Wechsel von 6.11 auf 6.2. Es waren nicht nachvollziehbar Daten verändert.

Bei einem Kunden war nachvollziehbar die Server-Festplatte defekt.

Nach einigem Suchen in verschiedenen anderen ADS-Datenbanken und bei einigen Kundeninstallationen hat konnte ich mit folgender Vorgehensweise ein Auftreten sochler korrupten Daten verhinden (bis jetzt).

HKEY_LOCAL_MACHINE
System/CurrentControlSet/Services/lanmanserver/parameters den Wert auf null setzen

Dies maximiert den Durchsatz des Netzwerkverkehrs. Gerade ADS Versionen nach 6.11 scheinen mir noch empfindlicher auf gestörte Netzwerkverbindungen zu reagieren als 5.7 bis 6.11.

"EnableOpLockForceClose"=dword:00000001"
Erzwingt das schliessen von offenen Oplocks beim Schließen oder Verlassen eines Programms

EnableSharedNetDrives - ist wohl selbsterklärend

SharingViolationDelay+SharingViolationRetries
Diese Einträge beeinflussen eigentlich nur das Startverhalten der Applikation. Und zwar dann, wenn bereits ein anderer Client auf die Anwendung (und damit auf die DB) zugreift. Nativ hat das mit dem ADS eigentlich nichts zu tun.

Das Grundproblem des ADS hier ist eigentlich das "nicht-validieren" der Inhalte. Ich habe schon einige Tabellen gesehen in denen ungültige Einträge vorhanden waren. Teilweise in Feldern, die kein User je zu Gesicht bekommt (AutiInc Felder - alle mit dem Wert 1!! ). Einige dieser Fälle habe ich dann dem Support zur Verfügung gestellt und trotz wirklichem Bemühen dort nie den wirklichen Grund nachvollziehbar bekommen.

Grus

Heik