Variable Textteile ganzen Texten zuordnen...

[TMC]

Hi,

und nochmal mehr eine Methodikfrage:

Ich habe eine View 1, folgende Feldinhalte:
Spalte 1 | Spalte 2
------------------------
27..          shgsjfd
28..          hkjhkl
29..          hkjhkjhk
3..            hkjhkjhkj
4..            hkjhkjhkj
500..        hgjhgl
501..        hkjhjhkjhkj
Das ganze sind 5stellige Postleitzahlen-Bereiche.

Dann gibt es eine View 2, in der z.B. konkret steht:
27123
27345
27456
30001
30002

Aufgabe:
In View 2 sollen Werte der Spalte 2 der ersten View angezeigt werden.
Herausforderung dabei:
Die PLZ-Kürzel der 1.View. Die sind auch nicht einheitlich. Einmal steht da ja '4..', dann wieder '501..'.

Wie kann man denn das logisch (z.B. mit Formelsprache) zuordnen?

TMC

[Semeaphoros]

Also, ich kann ja eigentlich nur mit 4stelligen Postleitzahlen umgehen und nicht mit fünfstelligen  ........ ... versuche es trotzdem:

Grundsätzlich, in einem Vieh lassen sich keine Werte aus einem anderen Vieh anzeigen. Das heisst, sämtliche Dokumente, die in Vieh 2 dargestellt werden, müssen zusätzlich ein Feld enthalten, in dem die entsprechend darzustellenden Werte abgespeichert werden.

Heisst: zum Bleistift im Querysave wird mit einer Lookup-Technologie der Wert aus Kolonne 2 der Vieh 1 herausgelesen.

Nun, mit Deinen Vorgaben gibt es da einen relativ komplizierten Vergleichsalgorithmus, der mit normalen Vergleichen nicht zu bewerkstelligen ist, muss also ausprogrammiert werden. Die Lösung sei dem geneigten Leser als Uebung überlassen ....  

Dabei gibt das wahrscheinlich ein Gemisch zwischen alphanumerischen und numerischen Vergleichen, um die Bedingungen genau erfüllen zu können.

Lösbar, aber nicht ganz einach.

[TMC]

Danke für die Infos.

Die Lösung sei dem geneigten Leser als Uebung überlassen ....  

Eben so sehe ich das auch :-)

Im Ernst, ich werde mal versuchen, das mit @Furmulas irgendwie hinzubiegen...


TMC

[koehlerbv]

Hi, TMC,

irgendwie riecht mir das nach "Kunde hat PLZ nnnnn" in einem Dokument und "Vertriebler ist zuständig für PLZ n...." - oder so ...

Funktionieren tut das m.E. nur, wenn die entsprechenden Infos in den Dokumenten selber stehen und dann in Ansichten ausgewertet werden - wie Semeaphoros schon geschrieben hat, lassen sich von Ansicht 1 nach Ansicht 2 keine Querverbindungen herstellen.

Sag mal noch ein paar Randbedingungen an ...

Ciao, herzliche Grüsse von Ober ... nach  Nieder ...
Bernhard

[Semeaphoros]

.... und darüber hinaus denke ich, dass die Lösung dieses Algorithmus für @Formulas zu komplex wird (wobei ich es durchaus für machbar ansehe)

[TMC]

Hi Bernhard,

Du hast wohl die richtige Nase :-)

Ihr habt Recht, Querverweise in Views gehen (leider) nicht.
Das ganze muss in Dokumente abgebildet werden.

Hab schon mal angefangen:

Folgende Formel ist in der Zielmaske (deren Doks dann auch in der View 2 im obigen Bsp. erscheinen soll).
_TempLookup1 := @DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; No  ; 2 );
@If(@IsError(_TempLookup1);
   "";
   _TempLookup1
))

Feld "No"
Hier steht die volle Postleitzahl

View "(LookupZIP)":
Enthält die Quelle (im obigen Bsp. also View 1);
Linke Spalte: PLZ-Kürzel, Zahlenfeld, kann 1-5 Stellen lang sein (also 22,3,555 etc.).
Rechte Spalte: Enthält Textfeld

Der @DBLookup klappt soweit schon perfekt, wenn in der Zielmaske dieselbe 5stellige PLZ eingetragen ist, welche auch in der View 1 existiert.

Nun müsste folgende Abfolge wohl in einer Schlaife / @If herhalten:
@DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; @Left(No;5)  ; 2 );
@DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; @Left(No;4)  ; 2 );
@DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; @Left(No;3)  ; 2 );
@DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; @Left(No;2)  ; 2 );
@DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; @Left(No;1)  ; 2 );
@Nix

Wie kann ich dass denn am performantesten lösen?
Will auch noch ein weiteres Feld einbauen, wo dann ein weiterer Wert der View "(LookupZIP)" ausgelesen wird.....

Hoffe meine Schilderung ist klar....

Grüße,
TMC

[Semeaphoros]

Du willst in R5 schreiben? Dann vergiss die Schlaifen für @Formeln, die hat Damien erst in der Version 6 eingebaut.

[TMC]

R5, Jens.

Na ja, Schlaife war wohl übertrieben, aber ein @If würde es doch auch tun.
(auch wenn es nicht der Definition einer Schleife entspricht wie ich sie ja selbst in die Schlaifendoku aufgenommen habe, weil die Anweisung ja nicht nur einmal im Code stehen würde sondern 5mal

Wenn @Left(No;5) nix bringt, dann mache @Left(No;4), wenn nix bringt, dann @Left(No;3).........

TMC

[Semeaphoros]

Ein Select oder Case Konstrukt wäre das.

Das deckt folgende Fälle wahrscheinlich nicht zwingend korrekt ab:

5..
52..
525..

[TMC]

Na ja, ich stelle mir halt die Frage, wie ich diese @If-Situation durchlaufen kann, ohne dass die KillPerformance-Falle zuschnappt aber ich damit alle PLZ's einfangen kann.

Max. werden 2 Tabellenwerte (Spalten 2 und 3 der View "(LookupZIP)") abgefragt werden.

TMC

[TMC]

OK, habe hier nun folgende Formel die das Ergebnis liefert wie ich es brauche:

_5 := @Left(No; 5);
_4 := @Left(No; 4);
_3 := @Left(No; 3);
_2 := @Left(No; 2);
_1 := @Left(No; 1);


_TempLookup5 := @DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; _5  ; 2 );
_TempLookup4 := @DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; _4  ; 2 );
_TempLookup3 := @DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; _3  ; 2 );
_TempLookup2 := @DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; _2  ; 2 );
_TempLookup1 := @DbLookup( "Notes" : "NoCache" ; ""  : ""  ; "(LookupZIP)"  ; _1  ; 2 );

@If(
   !@IsError(_TempLookup5);
   _TempLookup5;
   !@IsError(_TempLookup4);
   _TempLookup4;
   !@IsError(_TempLookup3);
   _TempLookup3;
   !@IsError(_TempLookup2);
   _TempLookup2;
   !@IsError(_TempLookup1);
   _TempLookup1;
   ""
)

Nach wie vor stören mich noch die vielen DBLookups, aber das läßt sich wohl nicht vermeiden  
In Summe habe ich dann 10 Lookups, wenn ich noch eine 2. Spalte anziehen möchte.

TMC

[Semeaphoros]

Das liesse sich bestimmt reduzieren. Für die zweite Kolonne reicht ein einziger Lookup, wenn man die Auswertung der ersten Kolonne zu Hilfe nimmt, und dann lässt sich die Lookup-Kaskade ja abbrechen, sobald man fündig ist, aber der Code wird dann in @Formula aber grad gar unübersichtlich.

[TMC]

Wie meinst Du das Jens?

Noch dazu gesagt sollte werden, dass keine logische Verbindung zwischen
- Spalte 1 und 2
und
- Spalte 2 und 3
besteht.

Unübersichtlichkeit ist mir hier zweitrangig, solange das ganze performant läuft.
Ist auch - so denke ich - eine Frage der Darstellung.

Letzterer von mir gepostete Code erscheint ja soweit übersichtlich, man könnte das ganze auch seeeehr unübersichtlich darstellen :-)

Ich sehe auch gerade, dass z.B. das "_5 := @Left(No; 5);" überflüssig ist. Habe ja nur 5 Stellen. Lasse es aber trotzdem. Wer weiß, vielleicht hat ja ab 2006 die Schweiz 6stellige PLZ's statt 4stellig, dann sind weniger Änderungen im Code zu machen :-)

TMC

[Semeaphoros]

Ja, aber, da der dblookup ja immer die erste Spalte für den Vergleich verwendet, müsste doch beim zweiten Nachschlagen dasselbe Dokument angesprochen werden .... oder?

Und dann, jedes gesparte dbLookup ist ein Performance-Gewinn. sprich, man müsste die Dinger so in @ifs einpacken, dass wirklich  nur solange Lookups gemacht werden, bis der Wert gefunden ist.


Jetzt wirst Du aber gleich Bauklötze staunen:


Die Schweiz hat 6stellige PLZen !! Und zwar von Anfang an. Das wurde nur nie publik. Intern arbeitet die Post schon seit eh und je mit 6stelligen, nur im Publikumsverkehr werden die "Nur 4stelligen" verwendet. Frag mich nicht, warum das so ist. Intern bekommen die PLZ alle noch 2 Stellen, die bestimmt irgend einen Sinn haben, dazu.

[TMC]

Ja, aber, da der dblookup ja immer die erste Spalte für den Vergleich verwendet, müsste doch beim zweiten Nachschlagen dasselbe Dokument angesprochen werden .... oder?
Und dann, jedes gesparte dbLookup ist ein Performance-Gewinn. sprich, man müsste die Dinger so in @ifs einpacken, dass wirklich  nur solange Lookups gemacht werden, bis der Wert gefunden ist.

Kann nur zu 50% folgen.
OK, immer 1. Spalte wird verwendet, ist noch klar für mich (die ersten 50% :-)).
Aber die Lookups werden doch immer gemacht, oder? Und ich kann ja auch das nicht beeinflussen wegen meinen @Left's ??

Die Schweiz hat 6stellige PLZen !! Und zwar von Anfang an. Das wurde nur nie publik. Intern arbeitet die Post schon seit eh und je mit 6stelligen, nur im Publikumsverkehr werden die "Nur 4stelligen" verwendet. Frag mich nicht, warum das so ist. Intern bekommen die PLZ alle noch 2 Stellen, die bestimmt irgend einen Sinn haben, dazu.

Na sieh mal einer an! Mein Code hat sozusagen die Ländergrenzen überschritten und schon fast die 6stelligen der Schweiz berücksichtigt!

Der Sinn dabei (öffentlich 4, intern 6) wäre aber interessant, u.a. für ne Notes DB  .
Also Zuordnung der 4stelligen PLZs zu 6 stelligen, die irgendwelche Meta-Zusatzinfos beinhalten.

Es müssten also Tables bei der Schweizer Post existieren, um die 4stelligen den 6stelligen zuzuordnen. Klassische Notes-Sache. Hat die Post bei Euch Outlook? Oder mailen die klassisch per Tinte + Papier (fremdgehen nicht erlaubt)?  

 
TMC

[Semeaphoros]

Also, ich glaub, ich kann Dir die anderen 50% nicht so ohne weiteres mit auf den Weg geben. A-Bär: Ueberleg mal folgendes:

Wenn Du die DBLookups statt mit Variable direkt in Deinem @IF-Statement einbaust (was dann aber arg unleserlich wird :-(, dann hast Du den Effekt, den ich meine: es werden nur solange DBLookups gemacht, bis die Bedingung WAHR wird. Problem ist hier natürlich, dass wir damit den Rückgabewert des DBLookup nicht mehr haben. Aber mit noch etwas mehr Unübersichtlichkeit lässt sich dieses Verhalten nachbauen, ohne die Rückgabewerte zu verlieren.

Weiter, das weitere Reduzieren der DBLookups lässt sich dadurch erreichen, dass man aus mehreren Resultatspalten des Vieh eine einzige Resultatspalte produziert, indem man die Werte mit einem Trennzeichen aneinanderreiht.

Also statt:

Spalte 1 | Spalte 2 | Spalte 3
------------------------------------
27..          W1            X1
28..          W2            X2
29..          W3            X3

Spalte 1 | Spalte 2
-----------------------
27..          W1~~~X1
28..          W2~~~X2
29..          W3~~~X3


Jetzt bekommt man mit einem einzigen DBLookup beide virtuellen Spalten als Rückgabe, das lässt sich dann aber mit einem Explode an der Markierung wieder auseinandernehmen.

[TMC]

Jetzt versteh ich was Du meinst :-)

Danke!

Beides sind prima Tipps (DBLookups in @If und nur ein Feld mit 2 Werten verwenden)

Grüße,
TMC

[Semeaphoros]

Also, das mit den Ifs ist so natürlich noch nicht ganz fertig, da muss trotzdem eine Variable dazwischen, damit Du am Schluss auch die Werte hast, aber das bekommst Du wohl schon hin.

Noch zur Post: Also wie das genau funktioniert, weiss ich auch nicht, und derzeit hab ich auch niemanden zur Hand, den ich fragen könnte. Die Umsetzung, die Du erwähnst ist simpel: wenn die Metainfo nicht bekannt ist, werden an die 4stelligen PLZ 2 Nullen angehängt, umgekehrt von den 6stelligen geht es immer zu den 4stelligen mit Entfernen der letzten beiden Zahlen, also da gibts bestimmt keine Tabellen. Das ist so systematisch, weil das von Anfang an so angelegt war.

Ansonsten, na, ich lass Dich mal raten, was die Post hier wohl im Einsatz hat ..... nur so ein Tip: beim Anruf bei einem Kontaktmann (Auftraggeber) innerhalb der Post: "In den letzten zwei Tagen hat unser Mail nicht funktioniert".

Vor wenigen Wochen waren alle Schalter-Arbeitsplätze während eines halben Tages tot! Gleichzeitig war auch das Portal von Postfinance (CH-Variante der Postbank) tot. Grund? Der SQL-Server Wurm hatte zugeschlagen ...........

[TMC]

Hab noch folgendes gefunden in einer Sandbox Tip Library:

More Efficient Formula Keywords

We have all experienced the frustration that comes with formula-based keywords loading even if the document is in read mode, thereby slowing down the opening of the document.  Well, here is a way to have your cake and eat it too - formula-based keywords that load only when they are used...
Rather than having the following code (or something similar) as your keyword formula:
list := @DbLookup(""; keyserver : keydb; keyview; keyname; 2);
@If@IsError(list); ""; list)

Try using the following code:
list := @If(!@IsDocBeingEdited; @Unavailable; @DbLookup(""; keyserver : keydb; keyview; keyname; 2));
@If(@IsError(list); ""; list)

The @IsDocBeingEdited keeps the keyword formula from firing until it is used.  The trick here is if the Keyword is "unavailable" (that is what the @Unavailable does) then it gets loaded when the user presses the Keyword icon or hits enter in the field.  You cannotreplace the @Unavailable with an empty string ("").  
I have tested this out and it works pretty well.  The only things you cannot use it with are keyword aliases, checkboxes, or radio buttons.
NOTE:  This does not work in layout regions.

TMC

[Semeaphoros]

Ja, irgendwie so ähnlich kannst Du die kaskadierende Abfrage auch machen. Bei dem Artikel ist es offenbar um Dokumentladezeiten gegangen. Der Grundansatz ist derselbe: Um Performance zu gewinnen, mach man den DBLookup nur, wenn er nötig ist.