Felder aus einer anderen Datenbank übernehmen

[marsu_2]

Hallo,

das Thema wurde ja schon öfters durchgekaut. Ich habe versucht nach folgendem Thread vorzugehen http://atnotes.de/index.php/topic,54521.0.html

Auf zwei probleme stoße ich dabei:

1. in der Ansicht meiner Source-DB habe ich die Spalte mit Alias folgender Maßen erstellen wollen:

Code

T_Name +" "+ T_Vorname  + "|" + @DocumentUniqueID

Dann kommt aber nur die Meldung "Falscher Datentyp für @Funktion text erwartet"

Ich habe es dann mit

Code

@Text

probiert was dann zumindest in der Spalte Vor/Nachname | Unid anzeigt.

Wenn ich dann ein Feld in der target DB als Dialogliste anlege und auf die Ansicht verweise kann ich auch normal die Namen aussuchen und speichern. Es wird aber der Name und nicht der Alias gespeichert! Zumindest sagen mir das die Dokumenteneigenschaften.

In dem Feld sind Synonyme zugeloassen

Wenn ich dann ein @GetDocField für ein anderes Feld nutze kommt im Frontend die Meldung "Feld PerNR: Ungültige Unid. Unid muss eine 32 stellige Hex-Zeichfolge sein,.  

[umi]

Hi

@DocumentUniqueID liefert die Special Text retour

Verwende @Text(@DocumentUniqueID) dafür.

Hast Du die Dokumenteneigenschaften angeschaut als das Dokument offen war?

[marsu_2]

wie geschrieben habe ich @text genutzt.

Ganz doofe Frage wie kann ich die Dokumenteneigenschaften ansehen wenn das Dokument geöffnet ist?

ich habe mit rechtklick->eigenschaften:Dokument -> und dann auf das Feld nachgeschaut.

[umi]

Hallo

Bei der Properties Box lässt sich durch klick auf den Titel umstellen, ob z.B. die Feld oder Documenteneigenschaften angezeigt werden sollen.

[marsu_2]

Ah man muss auf den Titel gehen :-)

Hier die Feld Eigenschaften:

Code

Feldname: Nachname
Datentyp: Textliste
Datenlänge: 45 Byte
Seq.-Num.: 1
Doppeleintrags-ID: 0
Feld-Flags: SUMMARY 

"Mustermann|99DCDC9DC5FD04B9C1257042002C0DC4"

Ich habe jetzt aber auch das Problem das in der Dialogliste auch beide Werte ID + Nachname angezeigt werden also Notes wohl nicht raft das es sich um ein Alias handelt?

Ich glaube das ging Freitag noch.

Ich habe mehere Spaltenformeln in der Source DB probiert.

Code

T_Name +"|"+ @Text(@DocumentUniqueID)

Code

T_Name +" | "+ @Text(@DocumentUniqueID)

Code

T_Name + " "+ T_Vorname +" | "+ @Text(@DocumentUniqueID)

Ich habe auch noch einen weiteren versuch gestartet.
Dem Feld Nachname habe ich eine Uid als Vorgabe gegeben, wenn ich dann ein neues Dokument erstelle in dem es ein weiteres Feld PersNR gibt das berechnet ist kommt nun die Meldung Feld_PersNR Dokument wurde nicht gefunden

Die einzigen Unterschiede zu dem Beitrag von Roalnd(pram) sind das meine Ansicht aus meheren Spalten besteht und das die erste Spalte, die mit dem Nachnamen/Uid, nicht versteckt ist. Aber das ist ja wohl nicht das Problem. Ach ja und die Spalte ist nicht kategorisiert aber sortiert.

[Tode]

Das ist eine Feldeigenschaft: Im englischen Client heisst das Ding "Allow keyword synonyms" (letzter Punkt in den Options auf dem zweiten Tab der Feldeigenschaften)..
Wenn die nicht gesetzt wird, dann kommt es zu dem von Dir geschilderten Verhalten...

[marsu_2]

Ich weiß! Das ist ja in der Beschreibung von Roland erklärt.

Die Eigenschaften von dem Feld Nachnamen:

[marsu_2]

also es bleiben beide Probleme.

Zum einen werden in der Dialogliste und in dem Feld immer beide, Nachname und Unid, angezeigt.

Das andere Problem was ich jetzt noch mal ausgetestet habe, wenn ich eine Unid direkt in das Feld eintrage ich über einen DBLockup den Vornamen oder andere werte bekomme wenn ich das über GetDocField mache

Code

@GetDocField(Nachname;"T_Pers")

bekomme ich immer nur die Meldung "Fehler: Dokument wurde nicht gefunden"

Ich frage mich gerade wie das mit der UNID überhaupt funktioniert? woher weiß der Befehl @GetDocField wo er das Dokument/Datenbank findet?

[Peter Klett]

Aus der Hilfe

@GetDocField:
Given the unique ID of a document, returns the contents of a specific field on that document. The document must reside in the current database.

[marsu_2]

Das habe ich beim durchstöbern gerade auch gelesen, aber das heißt doch de facto das die Erklärungen und Vorgehensweisen von dir Peter und anderen aus diesem thread http://atnotes.de/index.php/topic,54521.0.html nicht funktionieren?

Da ging es doch explizieht um unterschiedliche Datenbanken?

Also bleibt mir doch nur ein DBLockup mit allen Feldern in einem String den ich hinterher auflöse?

Oder habe ich irgend etwas übersehen?



 

[Peter Klett]

Doch, warum nicht? Habe ich in dem anderen Thema irgendwo etwas von @GetDocField geschrieben gehabt.

Generell geben wir hier Tipps in die (hoffentlich) richtige Richtung, dass dabei auch mal eine Nuance nicht ganz ausgereift sein kann - also nicht 100 %ig in den Kontext passt - , halte ich für normal. Der Rest nennt sich dann Transferleistung ...

Um an dem Beispiel des anderen Themas zu bleiben: Da habe ich geschrieben, dass ich nur die ID als Alias übernehmen würde, und mir dann später über die ID die restlichen Werte holen würde, um ein potentielles 32 kB-Problem von vorneherein einzuschränken.

Also die Liste aufbauen mit

Sichtbarer Wert1|ID1
Sichtbarer Wert2|ID2

und dann nachher über die ausgewählte ID (also den Alias) die restlichen Werte aus dem Dokument zu holen. In der gleichen Datenbank kannst Du das mit @GetDocField machen, ansonsten ein Lookup auf eine Ansicht in einer fremden Datenbank, in der die Dokumente nach ID sortiert sind.

Was sollte daran nicht funktionieren?

[marsu_2]

Hi Peter, bitte versteh das nicht als Angriff. Ich versuche nur die Unterschiede zwischen der einen und der anderen Methode zu verstehen.

Allgemein wurde gesagt mehrere @DBLockups sind bezüglich der performance nicht gut!?

Ich habe das dirty bisher immer so gemacht, kann aber auch nachvollziehen das das nicht sehr performant ist.

So wie ich es bisher verstehe bleibt mir aber nur die Entscheidung zwischen 32k Problematik also das mein String, den ich in der Source-DB zusammensetze, zu groß wird. Oder mehreren @DBLockups bei denen die Performance dann aber wieder leidet?

Ich verstehe nicht welchen Vorteil der Alias bei zwei unterschiedlichen DB's haben soll? Außer das er eindeutiger ist als vielleicht ein Name?

Den Vorteil den Marco nennt

Diese Funktion ist rasend schnell, weil sie über den ID-Index und nicht über eine Ansichtssuche geht.

gibt es dann ja nur innerhalb einer DB und nicht wenn ich auf eine andere DB zurückgreife richtig?

   

[cebolina]

Ich versuch mal, etwas Licht ins Dunkel zu bringen.

@GetDocField funktioniert nur innerhalb der selben Datenbank. Sobald eine zweite DB im Spiel ist, brauchst du @DBLockup.

Ich verstehe nicht welchen Vorteil der Alias bei zwei unterschiedlichen DB's haben soll? Außer das er eindeutiger ist als vielleicht ein Name?

Stell dir vor, es gibt zwei namensgleiche Personen (Fritz Müller). Beide Personen sind in der Ansicht enthalten. Hier gilt es die beiden anhand der UniqueID zu unterscheiden. Du könntest die Unterscheidung auch durch ein weiteres Kriterium erreichen - bspw. mit einer eindeutigen Personalnummer. Dann müsste deine Spalte etwa so aussehen:
Müller Fritz (4711)
Müller Fritz (0518)

Wenn du aber bei der UniqueID bleibst (wie mehrfach vorgeschlagen), wirst du die wenigsten Probleme haben.

Also:
1. Schritt
Über deine Dialogliste holst du die UniqueID des Personendokuments aus der zweiten DB.
2. Schritt
Über DBLookup holst du dann den Rest deiner Daten aus der 2. Datenbank. Als key dient hier die UniqueID aus Schritt 1.
Je nachdem wie die DBLookup-Ansicht aufgebaut ist, reicht hier EIN DBLookup. Dazu brauchst du in der 2. DB eine (versteckte) Ansicht, die in der 1. Spalte nach UniqueID soriert ist und in der 2. Spalte deine Feldwerte (durch ein beliebiges Trennzeichen getrennt) anzeigt. Hast du keine entsprechende Ansicht, brauchst du mehrere DBLookups.
3. Schritt (Annahme: es gibt eine Ansicht mit allen benötigten Feldwerten)
Aufteilung des DBLookup-Rückgabewertes

Allgemein wurde gesagt mehrere @DBLockups sind bezüglich der performance nicht gut!?

Annahme: Du willst 10 Feldwerte aus dem Personendokument holen.

Lösung 1:
10 DBLookups (ein DBLookup für jeden Feldwert) = 10 x Zugriff auf Server, 10 x Ansicht suchen, 10 x Dokument suchen, 10 x Dokument öffnen, 10 x Feldwert holen, 10 x Rückgabewert verarbeiten.

Lösung 2:
1 DBLookup (Rückgabe aller Feldwerte in einem String mit Trennzeichen) = 1 x Zugriff auf Server, 1 x Ansicht suchen, 1 x Dokument suchen, 1 x Rückgabewert verarbeiten.

Ich denke die Frage ist damit beantwortet ;-)

Gruß Stefan

[Peter Klett]

Nein, verstehe das nicht als Angriff. Manchmal kommt man neben dem Tagesgeschäft etwas griffiger rüber, als es angemessen wäre ...

GetDocField soll wirklich rasend schnell sein, aber natürlich  nur innerhalb der Datenbank.

Die von mir skizzierte Lösung hat den Vorteil, dass Du mit zwei kürzeren Abfragen klar kommst.

Die erste Abfrage gibt Dir die Auswahlwerte zurück, mit Alias (z.B. der UniversalID)

Wert1|ID1
Wert2|ID2
Wert3|ID3
usw.

Diese Liste könnte sehr lang werden. Wenn Du dann auch noch sämtliche Felder in den Alias packst, die Du nachträglich auslesen willst, kannst Du ein Größenproblem bekommen.

Unabhängig vom Größenproblem kannst Du auch Daten in den Alias bekommen, die die Auswahl zerstören, z.B. zu lange Daten (bin mir nicht sicher, ob das ein Problem geben kann, meine aber, sowas schon gehabt zu haben).

Natürlich könntest Du auch ohne Alias arbeiten, wenn die Werte eindeutig sind. Würde ich trotzdem sein lassen, da Du mit Alias zwei wesentliche Vorteile hast:

1. Du benötigst nur eine Ansicht nach ID, um im zweiten Lookup alle relevanten Daten zu bekommen, auch wenn Du u.U. in einer anderen Auswahlliste auf einen anderen Wert gehst

2. Hast Du in den Werten unerlaubte Zeichen, kannst Du die so problemlos umwandeln. Z.B. Komma kannst Du vergessen. Hast Du eine Liste von Nachnamen und Vornamen, sähe die Liste so aus

Meier, Hans|ID1
Müller, Erwin|ID2

Das kannst Du nicht auswählen. Das Komma durch einen Punkt ersetzt gibt

Meier. Hans|ID1
Müller. Erwin|ID2

Das wird den Anwender nicht wirklich stören, und im zweiten Schritt holst Du Dir mit der ID sowieso die korrekten Daten.

Ich hoffe, dass sind ein paar brauchbare Anregungen ...