Tabellen im MDE-Toolkit

System bleibt immer bei der ersten Tabelle stehen

Der Client baut die Verbindung auf, bleibt aber gleich bei der ersten Tabelle stehen und macht lange nichts, verbindet sich neu und steht erneut bei der ersten Tabelle.

In diesem Fall funktioniert der Handshake zwischen dem Client und dem Webservice nicht.
Eine mögliche Ursache sind die INI-Einstellungen für den Webuser und das Webpasswort. Die Einstellungen hierfür müssen in beiden INI’s (Client und Webservice) identisch interlegt sein.

Synchronisations Abbruch - nachvollziehbar immer an derselben Stelle

Syncabbrüche in einzelnen Tabellen kommen immer durch nicht sauber formatierbare XML-Strings, die für den Austausch zwischen Client und Webservice zum Einsatz kommen.

Als Ursache kommen zu meist:

• Sonderzeichen in Texten
• Ungültige Datumswerte (kleiner 01.01.1900 oder größer 31.12.2200)
• Werte, die die Formatvorgabe überschreitet (zB bei N(5,2) der Wert 1234,5)

Das Fehlerbild ist, dass immer an derselben Tabelle / Stelle die Statuszeile gelb wird:

Wichtig hier sind folgende Informationen:

• Welche Tabelle
• Welches ist der Zeitstempel, ab dem Versucht wird Tabelle noch zu synchronisieren

Vor allem der zweite Wert ist bei PC-Clients schwer herauszufinden, da der Sync zu schnell geht. Aus einem Infodialog geht das nicht hervor, da dies pro Gerät und Abfrage unterschiedlich ist. Der Wert könnte aus der Professional-MDE Tabelle MDETABLE aus dem Feld SYNTIMEST ermittelt werden. Dies ist im Normalfall umständlich bis unmöglich.

Eine Möglichkeit ist es die SQL-Protokollierung auf dem Webservice einzuschalten.

Hier ist der SWSWEB.INI folgende Zeile mit passendem Ziel einzutragen bzw. zu aktivieren:

PROT=E:\TEMP\WEB.TXT

In der Tabelle wird dann das Problem protokolliert. Leider aber nicht der Datensatz.
Wertet man die entsprechende Zeile aus, so hat man das relevante Datum ab dem es zu den Problemen kam.

Methode 1: Sichtkontrolle

Am besten kopiert man sich den String aus dem Protokoll komplett heraus und lässt das SQL-Statement im DBC ausführen.

Diese Methode funktioniert nur, sofern die Datenmenge übersichtlich ist und wenn der Fehler erkennbar ist. Es gibt eben auch unsichtbare Sonderzeichen.

Methode 2: Empirisch das Problem finden

Alternativ kann man auch versuchen das Feld zu bestimmen, indem man aus der Abfrage in der MDE-Verwaltung die Felder schrittweise verringert. Sobald man das fehlerhafte Feld entfernt hat funktioniert der Sync wieder. Nach dem erneuten Einfügen bleibt der Sync wieder stehen.

Diese Methode macht aber nur bei kleinen Tabellen mit vielen Feldern Sinn, da ja mit jeder Änderung an der MDE-Abfrage die Tabelle neu aufgebaut wird. Sind hier viele Tausend Sätze drin, so wird diese Methode sehr zeitaufwändig!

Methode 3: Webservice nutzen

Hierzu muss man auf dem Server, wo der Webservice installiert ist diesen aufrufen. Das geht dann auch mit http://localhost/SWSSeb/SWSWebService.asmx (Standardinstallation vorausgesetzt)

Hier wählt man die Funktion GetCursor aus.

Den Testdialog füllt man nun mit den aus dem Web-Protokoll ermittelten Daten aus. User und Passwort entnimmt man der INI des Webservice.

Hier ist das Verhalten nun etwas unterschiedlich, je nach Fehlerart:

Ist es ein Numerischer Überlauf, so wird nichts angezeigt. Man kann aber durch Feldreduktion auf das Feld kommen. Über die Zeiteinschränkung hat man dann nu eine kleine Zahl von zu untersuchenden Datensätzen. Der Fehler ist in der Regel dann schnell sichtbar.

Bei Sonderzeichen werden die Daten dann angezeigt, allerdings schlägt die Formatierung in das typische XML-Aussehen fehl. Der letzte angezeigte Datensatz (in Sonderfällen auch der darauffolgende nicht mehr angezeigt) ist dann der Datensatz, der die Probleme verursacht.

Synchronisations Abbruch - an verschiedenen Tabellen / Stellen

In diesem Fall wird die Statusleiste immer mal wieder gelb. Auch wird nicht immer dieselbe Tabelle angezeigt. Zeitweise läuft der Sync auch wieder komplett durch.

Der Grund ist hier immer in der aktuellen Last des Webservers zu suchen. Dies muss man sich so vorstellen. Die Anfragen werden vom Webservice zwar parallel in mehreren Tasks abgearbeitet. Dauern aber einzelne Prozesse zu lange, so kann es zu einem „Stau“ der Abarbeitung kommen. Das heißt, der Client bekommt in der Zeit, auf den er auf die Antwort wartet kein Feedback. Dies zeigt er dann als Syncabbruch an.

Sollte dies vermehr auftreten, so kann man die Timeout-Einstellungen des überprüfen und ggf. an die Gegebenheiten des Webservice anpassen.
Mögliche Parameter in der INI wären: