Serverdefinition nicht mehr case-sensitiv?

[leontopodiumalpinum]

Hi!

Ich habe ein sonderbares Phänomen:
Eine private Serverdefinition, die Freitag noch funktionierte, tut dies heute nicht mehr.
Die Definition "Kurs:" matcht nun auf "Dollarkurs:"!?
Sowohl heute als auch Freitag unverändert QC 3.1.6.1 im Einsatz.

LG Leo

---

Hi!

Ich habe ein sonderbares Phänomen:
Eine private Serverdefinition, die Freitag noch funktionierte, tut dies heute nicht mehr.
Die Definition "Kurs:" matcht nun auf "Dollarkurs:"!?
Sowohl heute als auch Freitag unverändert QC 3.1.6.1 im Einsatz.

LG Leo

Nachtrag: Kursaktualisierung Alle nach Start aktualisiert nur die Ansicht.

---

Noch ein Nachtrag:

Ich habe jetzt einen Workaround versucht,
zuerst in die Definition ein Blank davor eingefügt, das matcht unverändert auf "Dollarkurs:",
dann noch ein Komma davorgestellt, weil in der Site "....., Kurs:" steht, das matcht dann gar nicht mehr.

[zerus]

Dann versuche ich mal ein bisschen zu klären:

1. Groß- und Kleinschreibung
Die Parse Routine in QC nutzt den Textvergleich. Der ist unabhängig von Groß- und Kleinschreibung.
Das ist einer der Gründe für das seltsame Verhalten. Besser wäre wohl der binäre Vergleich, der Groß- und Kleinschreibung unterscheiden kann.

Nun weiß ich tatsächlich nicht mehr genau, was ich mir dabei vor 20 Jahren gedacht habe. Sprich es kann einfach so passiert sein oder ich hatte einen Grund, den ich jetzt nicht mehr weiß.

Ich könnte das angehen. Allerdings müsste ich alle Serverdefinitionen diesbezüglich nochmal checken. Was aber problematischer wäre, dass dies bei eigenen Serverdefinitionen bei Nutzern dazu führen könnte, dass einzelne eigene Serverdefinitionen nicht mehr funktionieren.

2. Freizeichen - Space
Vor dem Parsen wird der Suchstring mit einem Trim-Befehl von voran- oder nachgestellten Freizeichen befreit. Daher klappte das auch nicht bei Dir. Hintergrund ist, dass man so ein Freizeichen in der Serverdefinition ja kaum sehen würde, insbesondere wenn es nachgestellt ist. 
Nach Freizeichen in HTML zu suchen, ist auch insofern nicht ganz simple, da dieses ja unterschiedlich im Quelltext dargestellt werden kann. Innerhalb des Textstrings sollte es funktionieren, wenn im Quelltext der Seite auch tatsächlich " " ist und nicht etwa & nbsp;

3.   "....., Kurs:"
Warum das nicht geht, kann ich nicht sagen. Dazu müsste ich auch den Ausschnitt aus dem Quelltext sehen.

zerus

[leontopodiumalpinum]

3.   "....., Kurs:"
Warum das nicht geht, kann ich nicht sagen. Dazu müsste ich auch den Ausschnitt aus dem Quelltext sehen.

Serverdefinition:
:0E comdirect.de||https://www.comdirect.de/inf/aktien/[&isin]||||.||,||0||0||, Kurs:||||||||0||0||Stand:||||||||0||0||Stand:||.||||||0||0||Stand:||.||.||||0||0||[&minute]||||||||0||0||Stand:||:||||||0||0||Gehandelte St&uuml;ck||">||||||0||0||>Er&ouml;ffnung<||">||||||0||0||
>Schluss Vortag<||">||||||0||0||>Hoch<||">||||||0||0||>Tief<||">||||||0||0||__

Isin z. B:
DK0062498333

Dass es am Freitag noch ging, wird vermutlich an einer Umstellung der Site liegen, wodurch sich "Dollarkurs" entweder vordrängt oder überhaupt neu dabei ist, das war bis jetzt klarerweise nicht in meinem Fokus.
 

LG Leo

[zerus]

Ursache gefunden, warum ", Kurs" nicht funktioniert.

Vor dem Parsing werden die Einstellungen für Tausender-Zeichen und Dezimalzeichen gehandlet.
Das in der Serverdefinition eingestellte Dezimalzeichen (in diesem Fall das Komma) wird im gesamten Quelltext durch einen Punkt ersetzt. Somit können eben Zahlen mit verschiedenen Trennzeichen erkannt werden.

Fazit:
Ein Komma im Suchtext funktioniert dann nicht, wenn Du als Dezimal- oder Tausender-Zeichen ein Komma eingetragen hast.

Umgehungstrick: Statt dem Komma einen Punkt verwenden: ". Kurs" funktioniert.

zerus

[leontopodiumalpinum]

Hi!

Danke für die Antwort, ich habe zwischenzeitlich schlicht im 2. Suchfeld nochmal "Kurs:" eingegeben, hat auch funktioniert.
Der Trim-Hinweis war auch aufschlussreich, dadurch ist mir jetzt klar, weshalb Blank als Tausender-Trenner nicht funktioniert.

LG Leo