Relationsnamen müssen eindeutig sein, ist auch klar.
Wenn ich einen Relationsnamen X verwende, darf der auch als Tabellenname X existieren und die beiden beißen sich nicht?
Wenn ich mit LlDbAddTableRelation(Ex) eine Relation definiere, dann kann ich einen “LPCTSTR pszRelationDisplayName” angeben. Wo finde ich den angezeigt im Designer?
Ich schaffe es schon nicht, den “LPCTSTR pszRelationID” im Designer zu sehen. Da tauchen immer nur die Tabellennamen auf. Ist das so gewollt?
Die Relationen funktionieren im Designer einwandfrei und die Druck-Ergebnisse sind exzellent. Aber sobald ich einen Drilldown anlege, verschwinden Tabellen, manchmal auch erst beim zweiten Aufruf des Drilldown-Designers. Da ich davon ausgehe, dass ich nicht der erste bin, der Drilldowns verwendet, muss ich den Fehler erst mal bei mir suchen. Und da brauche ich Ihre Hilfe.
Grundsätzlich ist es kein Problem, wenn Tabellenname und Relationsname identisch sind - das wäre funktional in Ordnung, auch wenn es in der Praxis eher ungewöhnlich ist.
Zur Anzeige im Designer: Der Relationsname wird nur dann eingeblendet, wenn eine Relation nicht eindeutig ist - also z. B. wenn zwischen denselben Tabellen zwei unterschiedliche Relationen existieren. Ist die Relation eindeutig, spielt der Name für die Auswahl keine Rolle, daher wird er nicht angezeigt.
Das erwähnte Drilldown-Problem können wir in dieser Form aktuell nicht nachvollziehen. Gerne können wir uns das gemeinsam genauer ansehen.
Grundsätzlich ist es kein Problem, wenn Tabellenname und Relationsname identisch sind - das wäre funktional in Ordnung, auch wenn es in der Praxis eher ungewöhnlich ist.
-– snap —
Das war nicht ganz die Frage. Die ging in die Richtung: Sind die Wertebereiche Relationsnamen und Tabellennamen unabhängig. Aber aus Ihrer Antwort schließe ich, dass das so ist und dass das nicht zu internen Verwirrungen im L&L führen kann, wenn sogar Relations- und Tabellenname gleich sein dürfen.
— snip —
Zur Anzeige im Designer: Der Relationsname wird nur dann eingeblendet, wenn eine Relation nicht eindeutig ist - also z. B. wenn zwischen denselben Tabellen zwei unterschiedliche Relationen existieren. Ist die Relation eindeutig, spielt der Name für die Auswahl keine Rolle, daher wird er nicht angezeigt.
— snap —
Das ist schade, denn der Relationsname spiegelt die Rolle der verbundenen Tabelle wieder. Und der ist wichtiger als der Tabellenname.
Kommen wir noch zu den “Display Names” sowohl bei den Tabellen, als auch bei den Relationen. Ich hätte drauf getippt, dass es keine Syntaxeinschränkungen für diese Namen gibt. Das scheint aber durchaus der Fall zu sein und sobald man hier etwas bei den Tabellen angibt, ändert sich auch die Auflistung der Feldnamen. Hat das einen Grund, z.B. weil der Zugriff auf die Felder nun anders erfolgt/erfolgen kann?
Ein Frage habe ich noch zu den Feldnamen. Ist es zulässig, wenn ich auch das “@” für Feldnamen verwende? Mein LLDataProvider kann auf Wunsch auch Tabellen-Statusinformation als Felder einblenden, z.b. die physische Satznummer, die aktuelle Tabellen-Sortierung oder Löschstatus des aktuellen Satzes. Mit dem “@” am Anfang des Feldnamens tauchen die alle kompakt oben in der Feldliste auf und man kann sie gut von den eigentlichen Feldern unterscheiden.
Das ist schade, denn der Relationsname spiegelt die Rolle der verbundenen Tabelle wieder. Und der ist wichtiger als der Tabellenname.
Aus unserer Sicht ist das eher ungewöhnlich. Ansonsten könnte man den Display-Namen der verbundenen Tabelle entsprechend anpassen und die Rolle dort mit aufnehmen.
Kommen wir noch zu den “Display Names” sowohl bei den Tabellen, als auch bei den Relationen. Ich hätte drauf getippt, dass es keine Syntaxeinschränkungen für diese Namen gibt.
Da der Tabellenname eben genau das Präfix für Felder ist, gelten dafür die gleichen Einschränkungen wie für Felder. Das gilt auch für den Display-Name, der ja dann eher das “lokalisierte Präfix für Felder” ist.
Ein Frage habe ich noch zu den Feldnamen. Ist es zulässig, wenn ich auch das “@” für Feldnamen verwende?
Nein, das würden wir nicht empfehlen. In diesem Kontext ist das @-Zeichen für 1:1-Relationen sowie Benutzer- und Summenvariablen reserviert und kann daher zu Konflikten oder unerwartetem Verhalten führen. Als Alternative könnte ein Underscore (“_”) verwendet werden.
bitte verzeihen Sie, dass ich Ihren Vornamen zum Nachnamen gemacht habe. Der Nachname meines besten türkischen Feundes reimt sich perfekt auf ihren Vornamen. Ist wahrscheinlich deswegen passiert.
Was Sie mir geschrieben haben, hat mich nicht unbedingt in meiner Weltanschauung geändert, aber ich habe nun Ihre Sicht der Dinge kapiert. Sollte man vielleicht in der Doku schrieben, vor allem das mit dem Ausweichen auf den anderen Namen, wenn eine Tabelle doppelt per Relation verbunden ist.
Das “@” habe ich in ein “_” geändert und trotzdem hat sich mein Problem nicht gelöst. Leider.
Sobald ich im Designer in den Drilldown-Designer weiter gehe, sehe ich dort zwar die Sub-Table des Drilldowns, aber an der sind keine weiteren Sub-Tables mehr zu finden, die im ersten Designer angezeigt werden. Im DebWin4 sehe ich, dass Sie den Job einfach kopieren und damit im Drilldown-Designer weitermachen. Dazwischen habe ich eigentlich keine Gelegenheit, etwas falsch zu machen, denn die Tabellen+Relations-Definitionen sind ja unverändert.Trotzdem fehlt da die Tabelle fields_bg2.
Anbei schicke ich Ihnen einen Screenshot, auf dem man den ersten Report-Designer, den Drilldown-Designer und das DebWin4-Fenster sieht. Im Debwin4-Fenster sind alle Nachrichten selektiert, in denen “LLDBADDTABLE” zu finden ist, also meine Tabellen- und Relationsdefinitionen.
Wo kann ich noch nachsehen? Ich habe auch das DebWin4-Protokoll griffbereit, falls sie es haben wollen.
