db.search liefert ungewollte Ergebnisse

[Alexis]

Hallo Forum,

kann mir vielleicht jemand einen Fingerzeig geben, warum folgende beiden Searchformula nicht das selbe Ergebnis bringen:

searchformula$ = {Form = "Device" & Serialnumber = "}+SerialFrom+{" }
searchformula$ = {Form = "Device" & Serialnumber >= "}+SerialFrom+{" & Serialnumber <= "}+SerialTo+{"}

Die Variablen SerialFrom und SerialTo enthalten den Wert "GJR2394100R1210 81AA03A-E 9094   92", der tatsächlich exakt nur einmal in der DB vorkommt.

Im Debugger sieht alles korrekt aus:
Form = "Device" & Serialnumber = "GJR2394100R1210 81AA03A-E 9094   92"
Form = "Device" & Serialnumber >= "GJR2394100R1210 81AA03A-E 9094   92" & Serialnumber <= "GJR2394100R1210 81AA03A-E 9094   92"

Ergänze möchte ich, dass das Feld Serialnumber ein Mehrfachwert ist.

Danke für jeden Hinweis wo ich anzetzen könnte.

Alexis

[Axel]

Meines Erachtes müsste das so aussehen:

searchformula$ = {Form = "Device" & (Serialnumber >= "}+SerialFrom+{" & Serialnumber <= "}+SerialTo+{")}


Axel

[MadMetzger]

Ich glaube die Klammern sind an der Stelle überflüssig bzw dürfte keinen Unterschied machen.

Das ist ja etwa so vom Wesen her:
a & b & c = a & (b & c)

Ich frage mich nur gerade, ob der größer bzw kleiner-Vergleich auch bei Strings geht? Könnte ja gehen, wenn man die lexikographische Ordnung zu Rate zieht.

[Alexis]

Richtig Markus,

die Klammern haben keinen Einfluss, das Ergebnis ist exakt das gleiche.

Ob der größer bzw kleiner-Vergleich bei Texten greift erscheint mir eine sehr berechtigte Frage zu sein.

Ich versuche dem mal nachzugehen.

Danke zunächst.

Alexis

[Axel]

Ich glaube die Klammern sind an der Stelle überflüssig bzw dürfte keinen Unterschied machen.

Jain.  

Mit den Klammern kannst du die Auswertungsreihenfolge der Formel steuern.

Ich frage mich nur gerade, ob der größer bzw kleiner-Vergleich auch bei Strings geht?

Das hab ich auf die Schnelle übersehen. Ich glaube, dass dieser Vergleich bei Strings nicht möglich ist. Zumindest bei der Search-Methode. Ich lasse mich aber gerne vom Gegenteil überzeugen.

Axel
 

[MadMetzger]

Aber das Ergebnis sollte in dem Fall das gleiche bleiben.  Zudem kann man mit Klammern die Lesbarkeit steigern, was aber in diesem Fall aber nicht unbedingt viel bringen würde, da "dynamisch ermittelte" Suchformeln meistens schlecht lesbar sind...

Leider kann ich das mit den Strings hier nicht selbst testen... Sonst hätte ich das auch noch schnell gemacht...

[koehlerbv]

Grösser und kleiner funktioniert natürlich bei Strings und auch im Zusammenhang mit dbSearch.

Unsicher wäre ich eher auf Grund der Tatsache, dass es Mehrfachwerte sind. Arrays mit einem skalaren Wert zu vergleichen ...

Bernhard

[MadMetzger]

Da war ich mir gerade nicht sicher, ob das bei Notes geht mit Strings... Wie es gehen kann habe ich ja in meinem ersten Posting in diesem Thread geschrieben... Aber damit haben wir das schonmal geklärt... Danke Bernhard, wieder was gelernt!

Aber der Hinweis von Bernhard könnte schon zum Ziel führen... Denn mit der Abfrage hier erwischt man nur die Dokumente, bei denen die passende Seriennummer als Einzelwert drinnen steht. Evtl sollte man dann lieber mit @IsMember oder @Contains in der Suchformel arbeiten.

[Alexis]

Super Eure Anregungen!

Habe getestet: Stringvergleich ist (natürlich) möglich.

Der Fehler liegt sehr wahrscheinlich bei den Mehrfachwerten. In meinem Skript ermittle ich später ein Array mit der gefundenen Seriennummer. Und siehe da, wo ich früher ein Vorhandensein des Kriteriums fand ist dieses nun nicht mehr der Fall.

Also werde ich das Skript umbauen.

Alexis

[Alexis]

@ MadMetzger:

@IsMember etc. ist m.E. nicht anwendbar, denn ich möchte bei der Suche einen Seriennummern-Bereich auswerten, was durch direkten Vergleich praktisch unmöglich ist.

@ Bernhard:

Ich sehe leider keine andere Möglichkeit als den von mir beschrittenen Weg. Höchst unsauber ist meine ad hoc - Lösung: Ich durchforste die gefundenen Ergebnisse und überprüfe sie nochmals auf das gesuchte Intervall der Seriennummer, oder siehst Du einen anderen Ansatz?

Anbei: Ein Dokument (sprich Gerätetyp) kann einige hundert Seriennummern enthalten und in der Datenbank sind z.Z. mehr als 5000 Geräte vorhanden.

Bin leider etwas ratlos 

Alexis

[MadMetzger]

Okay, da hast du natürlich recht... das geht so nicht.

Hm... Interessantes Design: Ein Dokument je Typ und die vorhandenen Seriennummern in einem Mehrfachwertefeld... Sollte man das nicht vielleicht nochmal überdenken? Evtl kann man ja die Geräte mit den Seriennummern in Antwortdokumente verlagern, so das die Verknüpfung eines Gerätes mit seinem Typ erhalten bleibt...

[Alexis]

Hallo Marcus,

das Konzept ist bereits schon so kategorisiert, wie Du es vorschlägst: die Seriennummern sind in den Gerätedokumenten in einem Feld gespeichert.

Ziel der Suche ist es übrigens, bei Fehlern in einer Serie die entsprechenden Kunden herauszugekommen.

Bin aber unzufrieden, dass das nicht besser zu lösen ist. Bernhards Hinweis vermag ich nicht in einem konkreten Lösungsansatz umzusetzen.

Alexis

[MadMetzger]

Also gibt es pro Gerät schon ein Dokument, oder wie?

[Alexis]

Ja

[koehlerbv]

Aber warum stehen dann hunderte Seriennummern im Dokument? Und Du schreibst ja auch von "Gerätetyp" ...

Bernhard

[MadMetzger]

Genau aus dem Grunde habe ich nachgefragt... Warum suchst du dann nicht direkt nach den Gerätedokumenten?

[koehlerbv]

Ich denke, jetzt kommen wir vom Thema etwas ab - man kann das Problem ja auch allgemeiner sehen: Wie suche ich nach ranges in Strings in Mehrfachfeldern?

Die ideale Lösung wäre sicherlich:
1 Dokumenttyp "Gerätetyp"
1 Dokumenttyp "Gerät"
Dadurch auch nur eine Seriennummer pro Dokument, und man kann das einzelne Gerät zudem noch viel besser beschreiben (Auslieferung, Bemerkungen, Kunde, Standort, Historie). Aber auch das ist wieder zu konkret für das allgemeine Problem - siehe oben.

Ich sehe für das Kernproblem (wenn die Applikation nicht gerade gezogen werden kann oder soll) nur eine Möglichkeit (zumindest auf die Schnelle und so zwischendurch gepostet):
- Ermittlung der "Gleichteile" der Strings für "von" und "bis"
- Bilden einer DocumentCollection auf Basis des "Gleichteils" (mit dbSearch und @Contains oder mit einer kategorisierten Ansicht und GetAllDocumentsByKey (key, False))
- Und dann Loopings drehen ...

Bernhard

[Alexis]

Bernhard Du warst schneller, trotzdem meine Erklärung:

Tut mir leid wenn ich mich nicht deutlich genug ausgedrückt habe:

Jedes Gerät wird in zig Anlagen eingesetzt und wird in der Datenbank als ein Antwortdokument pro Anlage einmal geführt mit der Stückzahl n. In diesem Dokument sind nun alle n Seriennummern gespeichert, die in der Anlage vorkommen.

Dieses wiederholt sich hundertfach entsprechend der Vielzahl von Geräten, die in der Anlage vertreten sind.

Ich hoffe es ist jetzt ausreichend klar.

Alexis

[MadMetzger]

Ich glaube jetzt habe ich es verstanden... Ein Gerätetyp kann x-mal in einer Anlage verbaut sein und je Typ und Anlage gibt es ein Antwortdok mit allen Seriennummern der eingebauten Geräte?

Algorithmus hat ja Bernhard schon geliefert... Poste doch aber bitte hinterher, wie und ob du es hinbekommen hast... Einige sind bestimmt neugierig...

[Alexis]

Hallo,

ich habe mich für folgenden Weg entschieden:

- User wählt Gerätetyp und Seriennummernbereich aus
- Baue aus ersterem eine Collection über alle erfassten Geräte in der DB
- Untersuche dann per Schleife das Array mit allen Seriennummern auf Übereinstimmung
- Bei Erfolg wird das/die Dokument(e) in ein Ordner gestellt
 
Dieser Weg macht wohl auch dadurch Sinn, dass ich nicht ausschließen kann, dass Gerätefamilien ev. sogar gleiche Seriennummernbereiche verwenden (bitte nicht fragen warum). Der Zeitfaktor dürfte bei dem Ziel (Rückrufaktion) keine zu große Rolle spielen.

Danke für Eure anregenden Beiträge. Bei Erfolg setze ich ein "Daumen hoch".

Alexis