Datenmanager-Automatismus: Manuelle Datenfeldeinträge eines Quellobjekts (stilbasierte Instanz) auf alle weiteren Instanzen desselben Stils/Symbols übertragen

[HebHeb]

Ausgangsszenario

Wir arbeiten mit einem überwiegend klassenbasierten Datenmapping über eigene Datenbanken und zahlreiche individuelle Datenbankfelder als Ergänzung zu Stilparametern.

Zusätzlich haben wir pro Projekt eine Konstruktionsebene als „Stilübersicht“.
Dort sind alle stilbasierten Objekte und Symbole jeweils einmal platziert und über Datenstempel vollständig beschriftet, also mit allen relevanten Datenbanken und Datenfeldern. Diese Ebene dient uns im Grunde als projektbezogene Stilbibliothek/ Übersicht
 

Beispiel

Ein stilbasiertes Belag-/Wegobjekt erhält in Datenbank A, Datenfeld 1 einen manuellen Eintrag, z. B. die Regeldetailnummer.

Dieser Wert wird aktuell am Objekt in der Stilübersicht manuell eingetragen - da der Stil und dessen Parameter die gewünschte Info nicht vorsehen.
Alle weiteren Belag-/Wegobjekte, die denselben Stil verwenden, sollen diesen Eintrag automatisch übernehmen.

Bisheriger Workflow

Aktuell nutze ich dafür Skripte:

Ein Objekt liegt auf einer definierten Konstruktionsebene als Datenquelle.
Die dort manuell ergänzten Werte werden ausgelesen.
Anschließend werden diese Zusatzinformationen auf alle weiteren Instanzen im Dokument übertragen.

Das funktioniert grundsätzlich, aber:

unsere klassenbasierte Bauteilbibliothek wächst ständig,
die Anzahl der Datenbanken und Datenfelder nimmt laufend zu,
der Pflegeaufwand für die Skripte wird immer größer,
und ich verliere dabei zunehmend den Überblick.

Meine Idee

Ich würde die individuellen DB-Einträge gern direkt über den Datenmanager per Zuweisungsformel übertragen, statt dafür separate Skripte zu pflegen.

Die Formel bzw. Logik müsste im Prinzip Folgendes leisten:

ein definiertes Objekt auf einer bestimmten Konstruktionsebene (immer identische Benennung) als Quellobjekt erkennen (wenn wegen Fehlanwendung mehr als eine Instanz des Stils, nur die erste auswerten)
dessen Stilname oder Symbolname erkennen,
den Wert eines bestimmten Datenfelds an diesem Quellobjekt auslesen,
und diesen Wert auf alle weiteren Instanzen im Dokument übertragen, (sofern Stilname bzw. Symbolname identisch sind)

 

Hat jemand so etwas schon einmal umgesetzt oder weiß, ob das theoretisch im Datenmanager überhaupt möglich ist?

Kann der Datenmanager auf ein anderes, eindeutig definiertes Objekt im Dokument zugreifen?
Oder ist so etwas aktuell nur sinnvoll per Skript/Plug-in lösbar?
 

Ich weiß, dass perspektivisch wohl auch Stile selbst stärker mit DB-Feldern ergänzt werden können (so zumindest mal mittgeteilt bekommen)
Aber solange kann und möchte ich nicht warten.

Wer kann helfen? Ist das möglich?
Danke für jeglichen Denkanstoß zur Umsetzung!

[Viktor Frank]

Hallo @HebHeb

Ich denke du kommst deinem Vorhaben mit der Funktion =XTabellensuche() am nächsten
(Github Link)

Im Kern pflegst du eine Tabelle mit einem Schlüsselwert (bspw. Stilname) und den zugehörigen Eigenschaften.
Die =XTabellensuche() Funktion sucht in dieser Tabelle anhand des Schlüsselwertes einen gewünschten Rückgabewert.

Ergo pflegst du dann nicht eine Ebene mit Stilen & Eigenschaften - sondern eine Tabelle mit Such- und Rückgabewerten.

Die Tabellensuche-funktion sieht, für den Stilnamen als Suchwert und der 'Tabelle1' als Wertetabelle, bspw so aus:

=XTABELLENSUCHE(STILNAME; 'NotFound'; 'Tabelle':A1..A100; 'Tabelle':B1..B100)

 

 

Am 11.4.2026 um 15:34 schrieb HebHeb:

Hat jemand so etwas schon einmal umgesetzt oder weiß, ob das theoretisch im Datenmanager überhaupt möglich ist?

Ja - über verschiedene XTabellensuche-Funktionen.

 

 

Am 11.4.2026 um 15:34 schrieb HebHeb:

Kann der Datenmanager auf ein anderes, eindeutig definiertes Objekt im Dokument zugreifen?

Kurze Antwort: Nein - dafür ist er nicht konzipiert.
Lange Antwort: Theoretisch Ja da man auch im Datenmanager mit =Runscript() Skripte aufrufen kann - allerdings kommt es hier stark darauf an in wie, wo und in welcher Art Skripte aufgerufen werden.
Als üblichen Workflow kann ich das nicht benennen.

Hier eine kleine Beispieldatei:
XTabellensuche.vwx


LG

Viktor

Bearbeitet 12. April von Viktor Frank

[HebHeb]

Super Danke für den Input!
Der Tabellenansatz ist definitiv interessant und klingt nach einem sehr guten Workaround!
Nun muss ich noch ein wenig überlegen wie ich in den Datensets die eigentlich manuell und nicht durch Zuweisungsformeln erzeugten Felder künftig kenntlich mache.
Das war am bisherigen Konzept immer sehr schön, dass die Anwendenden direkt sehen konnten wo noch händisch aktiv eingetragen werden musste (weil "leer")...
Aber das sollte ja mit Texten wie "EINTRAG VORNEHMEN" wenn Quelle "leer" sicherlich realisierbar sein.

[Viktor Frank]

Hey @HebHeb

gerne

vor 21 Minuten schrieb HebHeb:

...einem sehr guten Workaround!

Wieso Workaround? Ich sehe das als Workflow - wo liegt das "around" ? 

 

vor 21 Minuten schrieb HebHeb:

die eigentlich manuell und nicht durch Zuweisungsformeln erzeugten Felder künftig kenntlich mache.

Das Datenset zeigt bereits mit den Icons neben den Felder an ob: 
- die Werte aus einer Zuordnung kommen
- eine Zuordnung hinterliegt, aber mit einem manueller Wert übersteuert wurde
- ein manuell eigegebener Wert erwartet wird



LG

Viktor

Bearbeitet 12. April von Viktor Frank

[Letti R]

Hallo,

 

ich habe vor kurzem ein Script über den Datenmanager aufgerufen um Einträge zu berechnen und bei mir ist das schlussendlich an der Performance gescheitert, da die entsprechenden Werte (scheinbar) bei jedem aktualisieren der Objekte neu berechnet wurden. Das hat zu enormen Performance Problemen geführt, obwohl das Script verhältnismäßig simpel war.

 

Mein Workaround dafür ist, dass ich tatsächlich einen Lookup Table angelegt habe wo ich alle möglichen Werte (zum Glück ist das in dem Fall möglich) per Script vorab berechne (bzw. nur dann, wenn ich die Tabelle aktualisiere) und dann die Wete per Tabellensuche wie von @Viktor Frank beschrieben abgreife.

 

Grüße,

Letti

[Viktor Frank]

Vielen Dank für den Einblick @Letti R!

LG

Viktor

[HebHeb]

vor 20 Stunden schrieb Viktor Frank:

Wieso Workaround? Ich sehe das als Workflow - wo liegt das "around" ? 

Natürlich ist das eine Lösung, und ich möchte auch gar nicht in Frage stellen, dass das grundsätzlich ein praktikabler Ansatz ist.
 

Ich muss aber noch einmal überlegen, ob das für unsere Arbeitsweise wirklich der richtige Weg ist.

Was mich daran stört:

• Die Tabelle müsste in jedem Projekt manuell gepflegt und fortgeschrieben werden.
• Der Wert wird nicht direkt am Objekt, sondern in einer separaten Tabelle gepflegt.
• Nach meinen bisherigen Tests funktioniert das offenbar nicht mit Tabellen, die Stile über Filter auflisten, sondern nur mit „echten“ Zellen wie A1, B2 usw. Subzellen wie A1.1 oder B1.2 scheinen nicht zu funktionieren.
  Damit fällt auch eine referenzierte, vordefinierte, zentral verwaltete und im laufenden Betrieb ergänzte „automatische“ Tabelle als Lösung weg.

Wir unterscheiden in unserer Arbeit zwischen referenzierten „Standard“-Stilen aus einer zentralen Vorlage, die ich zentral pflege, und nicht referenzierten projektspezifischen Stilen, die auf Basis bereitgestellter Dummys projektbezogen individualisiert werden.

In solchen Projekten entstehen naturgemäß zahlreiche individualisierte Stile, die im laufenden Betrieb auch immer wieder umbenannt werden. Gerade deshalb brauchen wir büroübergreifend Lösungen, die für alle reproduzierbar funktionieren und nicht nur für diejenigen, die sich tiefer in die Software einarbeiten.
 

Genau hier sehe ich beim manuellen Nachpflegen von Tabellen zu viel Fehlerpotenzial – insbesondere dann, wenn weitere Datenfelder oder ganze Datenbanken hinzukommen. Korrekturen und Fortschreibungen könnte ich dann auch nicht mehr ohne Eingriff in die Projektdateien automatisch ausrollen. Stattdessen wäre in jedem Projekt und durch jeden Bearbeiter ein manueller Eingriff in eine Datenstruktur nötig, die leider nicht jeder versteht oder sich damit gerne beschäftigt.
 

Hinzu kommt, dass wir tatsächlich nur ein einziges büroweites Datenmapping pflegen. Das bedeutet: Es wird im laufenden Projektbetrieb einfach neu eingeladen, und Fortschreibungen oder Korrekturen kommen bei allen ohne weiteres Zutun an. Eine Tabellenlösung beziehungsweise Tabellensuche müsste diesem Prinzip also ebenfalls folgen: Die Administration darf nicht beim Projektbearbeiter liegen, sondern ausschließlich die Dateneingabe.
 

Der Skriptansatz „Objekte auf einer Ebene pflegen > ausführen > fertig“ ist aus meiner Sicht für Kolleg:innen mit geringerer softwaretechnischer Affinität deutlich zugänglicher.
 

Vielleicht muss ich also doch noch einmal meinen werten Kollegen Claude hinzuziehen, um die Skripte besser verwaltbar zu machen – gegebenenfalls sogar, indem ich ihn mit meiner Datenmapping-XML „füttere“, um Teile davon zu automatisieren. Oder übersehe ich hier einfach was?

 

[Viktor Frank]

Hallo @HebHeb

Generell verstehe ich deine Argumente - ich glaube manche Themen sind jedoch dem Workflow übergeordnet.
 

vor 52 Minuten schrieb HebHeb:

Die Tabelle müsste in jedem Projekt manuell gepflegt und fortgeschrieben werden.

Nunja, das liegt in der natur der Sache - jedes Projekt ist eben unterschiedlich und individuell.
Ich denke kein Workflow ändert diese Tatsache.

 

vor 52 Minuten schrieb HebHeb:

Der Wert wird nicht direkt am Objekt, sondern in einer separaten Tabelle gepflegt.

Ich sehe das als Vorteil - die Werte sind zentralisiert in der Tabelle gespeichert.
Wieso einen Wert N-mal am Objekt speichern wenn es auch ein mal in der Tabelle geht?
Am Ende lässt sich bei Bedarf auch der einzelne Wert am Objekt überschreiben.

 

vor 52 Minuten schrieb HebHeb:

Nach meinen bisherigen Tests funktioniert das offenbar nicht mit Tabellen, die Stile über Filter auflisten, sondern nur mit „echten“ Zellen wie A1, B2 usw. Subzellen wie A1.1 oder B1.2 scheinen nicht zu funktionieren.

Richtig - die Funktion =XTabellensuche() kann nicht auf Zellen von Objektlisten (Subzelle) zugreifen.
 

vor 52 Minuten schrieb HebHeb:

Damit fällt auch eine referenzierte, vordefinierte, zentral verwaltete und im laufenden Betrieb ergänzte „automatische“ Tabelle als Lösung weg.

Wieso? Es findet lediglich die Pflege der Parameter an einer anderen Stelle, in der Tabelle, statt. Bisher pflegt ihr diese Werte eben auf einer eigenen Ebene.
Über eine Excel-Referenz könnte die Tabelle auch ausserhalb von Vectorworks auf dem Server liegen.
 

vor 52 Minuten schrieb HebHeb:

In solchen Projekten entstehen naturgemäß zahlreiche individualisierte Stile, die im laufenden Betrieb auch immer wieder umbenannt werden. Gerade deshalb brauchen wir büroübergreifend Lösungen, die für alle reproduzierbar funktionieren und nicht nur für diejenigen, die sich tiefer in die Software einarbeiten.

Die hier gestellten Ansprüche (büroübergreifend, reproduzierbar, nutzbar für "einfachen User") sehe ich als erfüllt.
Lediglich das Datenmanager-Setup sollte vielleicht jemand machen der sich auskennt.
Am Ende müssen die User nur eine Tabelle pflegen... Ich denke dafür muss man kein Vectorworks-Profi sein.
 

vor 52 Minuten schrieb HebHeb:

Der Skriptansatz „Objekte auf einer Ebene pflegen > ausführen > fertig“ ist aus meiner Sicht für Kolleg:innen mit geringerer softwaretechnischer Affinität deutlich zugänglicher.

Das ist sicherlich richtig - die Problemmatiken mit dieser Methode hast du jedoch im Eingangspost beschrieben....
Orga, Wartung und Aktualisierung liegen dann eben bei dir
Mitarbeiter wenig Aufwand - HebHeb viel Aufwand.

 

vor 52 Minuten schrieb HebHeb:

Vielleicht muss ich also doch noch einmal meinen werten Kollegen Claude hinzuziehen, um die Skripte besser verwaltbar zu machen – gegebenenfalls sogar, indem ich ihn mit meiner Datenmapping-XML „füttere“, um Teile davon zu automatisieren. Oder übersehe ich hier einfach was?

Das geht sicher – ich selbst gerne LLMs für meine Skripte und Anliegen.
Ich rate jedoch zur Tabellen- und somit Bordmittellösung, da sie einfacher zu warten und nachzuvollziehen ist.
Individuelle Skripte sind zwar technisch elegant, aber unternehmerisch riskant.
Es entsteht eine kritische Abhängigkeit: Verlässt der verantwortliche Experte das Unternehmen, bricht die Wartbarkeit zusammen, da das nötige Fachwissen zur Pflege der Logik nicht mehr im Haus ist.
Daher rate ich immer von "Sonderlösungen" ab - Arbeitsmethodik sollte so ausgerichtet sein, dass sie möglichst nicht von einer Einzelperson abhängt.
 

Ich denke als Vectorworks-Veteran hast du einen guten Überblick :) 

Viktor

Bearbeitet 13. April von Viktor Frank

[Letti R]

Hallo,

 

vor einer Stunde schrieb Viktor Frank:

Individuelle Skripte sind zwar technisch elegant, aber unternehmerisch riskant.
Es entsteht eine kritische Abhängigkeit: Verlässt der verantwortliche Experte das Unternehmen, bricht die Wartbarkeit zusammen, da das nötige Fachwissen zur Pflege der Logik nicht mehr im Haus ist.
Daher rate ich immer von "Sonderlösungen" ab - Arbeitsmethodik sollte so ausgerichtet sein, dass sie möglichst nicht von einer Einzelperson abhängt.

 

Das muss nicht unbedingt der Fall sein. Fairerweise bin ich aber voreingenommen, da ich gerne scripte.

 

Wie zuvor erwähnt fülle ich per Script eine Lookup Tabelle aus dem ich dann die Werte per Tabellensuche mit dem Datenmanager entnehme.

Wenn sich niemand mehr um das Script kümmert, dann ist es (mit etwas Mehraufwand) weiterhin ohne Probleme möglich die Tabelle in Vectorworks händisch zu führen.

 

Analog dazu könnte @HebHeb z.B. ein Script schreiben das alle Objekte auf einer gewissen Konstruktionsebene die eine gewisse Datenbank angehängt haben automatisch ausliest und daraus eine Tabelle in Vectorworks generiert, auf die dann per Tabellensuche über den Datenmanager zugegriffen wird.

 

vor 2 Stunden schrieb HebHeb:

Nach meinen bisherigen Tests funktioniert das offenbar nicht mit Tabellen, die Stile über Filter auflisten, sondern nur mit „echten“ Zellen wie A1, B2 usw. Subzellen wie A1.1 oder B1.2 scheinen nicht zu funktionieren.

 

Dafür hatte ich mal ein WS Script geschrieben, welches es ermöglicht auch in Suzellen zu suchen. Aber das hilft in diesem Fall nicht weiter, da man damit ebenfalls die Performance Probleme haben wird, weil Script.

 

 

Grüße,
Letti

[HebHeb]

Danke! Ich denke, das ist hier ohnehin für alle Mitlesenden spannend, wenn es dazu eine Diskussion gibt – ganz abgesehen von konkreten Anregungen für eine erfolgreiche Umsetzung.
 

Ich finde auch, dass du recht hast, und deine Argumente sind genauso gültig wie meine. Das ist ja meines Erachtens eine der wahren Stärken von Vectorworks: dass man es so anpassen kann, wie man es selbst braucht.
 

Nach einigen Jahren, in denen ich inzwischen fulltime kaum noch Projektarbeit mache, sondern fast nur noch CAD-/BIM-Organisation, Entwicklung, Strategie und den Support für ganz unterschiedliche Anwendercharaktere im 1st- und 2nd-Level betreue, hat sich meine Sicht darauf, wie ein Workflow aussehen kann, enorm verändert.
 

Der Alltag zeigt leider, dass selbst eine Tabelle – für uns hier im Forum Aktive kaum vorstellbar, selbst dann nicht, wenn die Umsetzung dokumentiert ist – eine ansonsten durchdachte Automatisierung bzw. Arbeitsweise gefährden kann.
 

Je weniger überhaupt noch in Zellen oder Formeln editiert werden muss, desto besser und zuverlässiger ist es.
Ich rede hier auch von perspektivisch mehreren Hunderten von individuellen Datenfeldern.
 

Daten direkt in Datensets am Objekt, gegliedert nach LOIN, also „von oben nach unten“ durcharbeiten und Werte aus Pop-up-Listen auswählen: Das funktioniert dagegen sehr zuverlässig.

Das Datenset ist nach jeder Anpassung durch einmaliges Importieren wieder auf dem aktuellen Stand – und zwar gleichzeitig in allen dutzenden Projekten. Das ist mein Ansatz.
Die damit kommunizierenden Datenstempel sind standardisiert und aus einer zentralen Vorlage referenziert – die ziehen also ebenfalls automatisch mit.

Das ist ein Grundprinzip, das sich in unserer Arbeitsweise auf viele Ebenen übertragen lässt.
 

Nichtsdestotrotz werde ich die Tabellensuche nicht ungeachtet lassen und experimentieren! Ich denke da auf jeden Fall noch einmal darüber nach. Solche Themen und Workflows entstehen ja auch prozesshaft und nicht von heute auf morgen

 

vor 1 Stunde schrieb Viktor Frank:

Das geht sicher – ich selbst gerne LLMs für meine Skripte und Anliegen.
Ich rate jedoch zur Tabellen- und somit Bordmittellösung, da sie einfacher zu warten und nachzuvollziehen ist.
Individuelle Skripte sind zwar technisch elegant, aber unternehmerisch riskant.

Schon vor dieser Ära habe ich geskriptet und ähnliche Dinge gemacht – ein gewisses gefährliches Halbwissen ist also ohnehin vorhanden. Und ja, auf das unternehmerische Risiko im KI-Hype weise ich ebenfalls immer wieder hin.


 

[HebHeb]

vor 1 Minute schrieb Letti R:

Analog dazu könnte @HebHeb z.B. ein Script schreiben das alle Objekte auf einer gewissen Konstruktionsebene die eine gewisse Datenbank angehängt haben automatisch ausliest und daraus eine Tabelle in Vectorworks generiert, auf die dann per Tabellensuche über den Datenmanager zugegriffen wird.

Beziehungsweise direkt von Quellobjekt zu Zielobjekt schreiben (ohne Tabelle) wie ich das aktuell auch mache  
Für diese Datenfelder gibt es dann gar keine Datenzuweisungsformel ;D

[Viktor Frank]

Hallo zusammen,

in der Tat eine interessante Diskussion
Danke euch für die Einblicke in eure Arbeit.
Alles valide Wege - am Ende steht und fällt es wie immer mit der Person die die Wege ebnet, pflegt und den Kolleg/innen zeigt !

 

vor 47 Minuten schrieb HebHeb:

Schon vor dieser Ära habe ich geskriptet und ähnliche Dinge gemacht – ein gewisses gefährliches Halbwissen ist also ohnehin vorhanden. Und ja, auf das unternehmerische Risiko im KI-Hype weise ich ebenfalls immer wieder hin.

Ich weiss !  Ich lese deines Posts seit ich noch @GSP_nowhere war.


Liebe Grüße und viel Erfolg 

Viktor 

Bearbeitet 13. April von Viktor Frank