Phänomen bei Alphanummerischen Schlüsselfeldern

[Ronny]

Hallo

ich habe eine Datei mit einem alphanummerischnem Schlüsselfeld - 3 A. Die Datei beinhaltet 7 Sätze - für jeden Wochentag einen. Die Inhalte der Schlüsselfelder lauten dementsprechend: Mon, Die, Mit, .. . Son (in groß/klein Schrift).

Wenn ich jetzt aus dem RPG-Programm einen Chain mache, ist es dem System egal, ob in dem Keyfeld 'Mon', 'MON', 'mon', 'mOn' oder eine andere Kombination aus groß/klein Buchstaben steht, der Satz wird gefunden.

Weis jemand, wie ich diesen Efekt abstellen kann? An den Parametern zu der Dateidefiniton fällt mir nichts auf, womit das möglich wäre.

Gruß
Ronald

[malzusrex]

hy Ronald,

schau mal was bei der Datei im Paramter SRTSEQ steht.
ich habe das eben mal kurz getestet. Wenn dort *LANGIDSHR steht, dann kommt es zu deinem Phänomen. Wenn Du dort *LANGIDUNQ eingibst, dann funst es eigentlich ganz gut. einfach mal mit CHGPF nachschauen und gegebenenfalls ändern.

Gruß
Ronald

[Ronny]

Hallo

Der Parameter steht bereits auf "*LANGIDUNQ".

Die Datei ist nicht von mir, sondern Teil unserer Standardsoftware, deshalb möchte ich nicht daran herumspielen. Sonst laufen am Ende andere Dinge nicht mehr.

Da ich den eingegebenen Wert nicht speichern sondern nur testen muss ist das evt. sogar ein ganz angenehmer Effekt.

Aber komisch finde ich das schon.

Vielen Dank für die schnelle Antwort

[Fuerchau]

Sobald mit einem *LANGIDxxx gearbeitet wird, gibts diesen Effekt.
Eine Eindeutigkeit ist ausschließlich bei *HEX gegeben.

[rpg3]

Hallo Roland,

wird die Bezugszahl bei not found gesetzt ? Du kannst aber auch einen SETLL und einen READE machen.
Ich habe soetwas nocht nicht gehört, das ein CHAIN mit einem KEY nicht richtig funktioniert. Da muss was anderes sein. Wenn ich auf ein Datei mit dem KEY zugreife, und der Satz ist vorhanden muss der Satz gefunden werden.

Gruß HP

[Ronny]

Hallo HP

es werden ja auch Sätze gefunden - allerdings zuviele.

Es gibt ein Satz mit dem Schlüsselwert 'Mon' (grosses 'M' kleines 'on'). Wenn ich jetzt aus einem Programm heraus mit dem Schlüsselwert 'MON' oder 'mon' zugreiffe, wird trotzdem der Satz mit dem Schlüssel 'Mon' gefunden.

Eine Bezugszahl habe ich nicht angegeben. Der Settl/Read liefert das gleiche Ergebnis wie der Chain.

Gruß
Ronald

[Fuerchau]

Das liegt nun mal an der *LANGxxx-Einstellung der Datei.
Groß/Kleinschreibung sind daher gleichwertig, so dass halt ein Satz gefunden wird. Dies ist ja der Vorteil von *LANGxxx (Sortierung von Namen nach z.B. Telefonbuch).
Der Unterschied zwischen *LANGSHR und *LANGUNQ ist nur die Sortierfolge, nicht die Wertigkeit.

Nur *HEX liefert einen Fehler.
Möchte man im Programm sicher sein, das der HEX-Wert identisch sein soll, muss man halt das gelesene Feld nochmal mit dem Suchfeld vergleichen. Dies ist in RPG immer ein Hexvergleich.

[B.Hauser]

Was wenn Du eine zusätzliche logische Datei mit SRTSEQ *HEX anzulegen und zu verwenden?

Birgitta

[Fuerchau]

Ich würde eher den Effekt nutzen und das gelesene Feld wieder dem Benutzer/Programm zur Verfügung stellen so dass die Einheitlichkeit der Daten gewährleistet ist. Schließlich kommt die Datei ja bereits mit der Einstellung.
Egal was der User eingibt, aus MON, mOn, MOn usw. wird halt immer Mon. Find ich doch Klasse, dass das so geht.

[BenderD]

da wäre ich vorsichtig, "Standard" Software, die so einen Huddel macht, rumpelt damit beim Release Wechsel garantiert von den Schienen.

mfg

Dieter Bender,
der meint wenn man das haben will, dann speichert man UPPER(ebbes)

Was wenn Du eine zusätzliche logische Datei mit SRTSEQ *HEX anzulegen und zu verwenden?

Birgitta

[Fuerchau]

*LANGSHR/*LANGUNQ haben schon ihre Berechtigung. Mit UPPER gehts nur in SQL (in DDS benötige ich ein Hilfsfeld, was aber einen Update/Write in RPG verhindert) und hat eine andere Bedeutung.
Und was dann einen Releasewechsel angeht, dann muss das auch in Zukunft funktionieren.