Kai's Forum Users
6th March 2001, 01:00
Hallo,wir haben BIVc4 auf SQL-Server 7 zu laufen und bekommen beim Zugriff auf Daten über einen ASCII-Index teilweise Fehler (Suchen, Blättern), wenn Umlaute in Schlüsseln stecken (z.B. Suchbegriff Kunde oder andere Schlüssel mit Umlauten).
Das jeweilige Programm bricht mit "Wrong row returned (305)" ab.

Das klappt auch ganz simpel beim Blättern mit General Table Maintenance.
Die Fehler treten mit demselben Datenbestand nur auf dem SQL-Server auf, mit ORACLE gibts keine Probleme. Abfragen mit der SQL-Console direkt am Server laufen sauber, auch wenn ich nach dem Hash-Wert des entspr. Index ordnen lasse.
Kennt jemand dieses Verhalten? Neues Portingset (6.1c.05.02) hat nicht geholfen.Uwe

Kai's Forum Users
8th March 2001, 01:00
Hallo,
wir haben auch dieses Problem gehabt. (AIX, Informix 7.36, Baan IVc4).
Geholfen hat: User verwalten in Baan, Seite 3, Locale: ISO_BIN. Allerdings sehen
danach die Suchmasken in Baan etwas "wild" aus. (Statt ZZZZZ steht überall yyyyy mit Ü-Strichen). Vielleicht hilft es euch ja auch...

Kai's Forum Users
9th March 2001, 01:00
Hallo,
in der Ecke hätte ich nicht gesucht, wohl eher noch bei den Server-Einstellungen.>Locale: ISO_BIN. Allerdings sehen

>danach die Suchmasken in Baan etwas "wild" aus. (Statt ZZZZZ steht überall yyyyy mit Ü-Strichen). Vielleicht hilft es euch ja auch...
Bann schränkt beim Select wohl auf den in Suchbereich angegebenen Zeichenvorrat ein, der stand für ISO-8859-1 bei uns auf 1--127, Umlaute liegen eben dahinter. Wenn Ihr das komische Y nicht sehen wollt, kann man den Bereich nach oben auf den letzten sinnvollen deutschen Buchstaben (ü) begrenzen (dazu Max-Werte für ISO-BIN in tttss0104m000 auf 252 setzen, mit tttss0103m000 Runtime-Dateien davon erzeugen, user neu einloggen). Schränkt man auf "Z" ein, findet man natürlich keine Datensätze mehr, die mit Umlauten beginnen, das ist also nicht sinnvoll.Also nochmal Danke und tschuess

Uwe