Nein auf keinen Fall. Du änderst ja nichts an der Datenbanktabelle, wenn die Oberfläche neu generierst.Gehen die Daten dann auch verloren?
msfox hat geschrieben: ↑06.05.2022 07:57Nein auf keinen Fall. Du änderst ja nichts an der Datenbanktabelle, wenn die Oberfläche neu generierst.Gehen die Daten dann auch verloren?
Wenn es richtig gemacht wurde, wurde die PflegeOberfläche auch nicht direkt auf der "Transparenten Tabelle" gemacht. Man legt hierzu ein DatenbankView (Typ: Pflege-View) an und generiert darauf dann die Pflege-Oberfläche über den Tabellen-PflegeGenerator.
Vorteil:
- man könnte technische unterchiedliche PflegeViews für die gleiche Tabelle erstellen
- man kann am DB-View noch Zusatzangaben wie z.B. "Schlüsselspalte" (o.s.ä. bin gerade nicht im SAP) machen. Damit wird man beim Starten des Customizings schon gefragt, zu welchen Schlüsselwerten man die Einstellungen machen will. Wichtiger ist es aber für ViewCluster, wo man diese Felder für die Verknüpfung von unterschiedlichen PflegeViews verwendet.
--
Warum meine ausführliche Darstellung: Weil ich aktuell einige solcher Views anlegen musste, da der damalige Entwickler hier leider "geschludert" hat.
Wenn man es nicht gleich ordentlich macht, holt es einen immer ein...
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ZF_SAPler
Genau so habe ich es auch gemacht.black_adept hat geschrieben: ↑06.05.2022 12:19Hier möchte ich Ralf widersprechen. Wenn du eine Tabelle hast die nicht in eurem Kundennamesraum liegt würde ich die Finger von der Neugenerierung des Pflegeviews lassen. Denn damit kann sich der Eigentümer der Originalpflegeviews nachher auf "unerlaubte Änderungen am Standard" herausreden.
Wenn du die Tabelleninhalte pflegen möchtest: Leg dir einen eigenen Maintenanceview auf die Tabelle und generiere dir da einen Tabellenpflegedialog. Der ist in eurem Z-Namensraum und de facto kannst du dann alles machen was der Originaldialog auch konnte. Evtl. ist das ja sogar so gewollt, dass du dann nur eure ZZ-Append-Felder zur Pflege anbietest und auch nur "Ändern" und nicht "Anlegen und Löschen" zulässt. Letztere Aktionen würde ich dann wieder dem Originalpflegedialog überlassen.
ralf.wenzel hat geschrieben: ↑06.05.2022 13:18Er hat gesagt, die Tabelle liegt im Kundennamensraum. Ich MEINE mich zu erinnern, dass diese Meldung immer kommt, wenn man Pflegedialoge neu generiert.
Ralf
Was nicht SAP-Namensraum ist, ist Kundennamensraum. Der Kunde ist in diesem Fall das Beratungsunternehmen. Dann ist es naheliegend, mit denen in Kontakt zu treten, welches Verfahren die für deinen Fall vorgesehen haben.
Es gibt doch Namensräume, die weder dem (End)Kunden gehören noch der SAP. Dafür reserviert doch SAP die Namensräume, die mit "/" beginnen und z.B. von Beratungshäusern verwendet werden.ralf.wenzel hat geschrieben: ↑06.05.2022 13:25Was nicht SAP-Namensraum ist, ist Kundennamensraum. Der Kunde ist in diesem Fall das Beratungsunternehmen.
Die DB hält die Daten und Views sind wörtlich übersetzt Sichten auf diese Datenbanktabelle. De facto werden also durch den View Daten in der zu grunde liegenden DB geändert. Und da ist es egal mit welchem View du das machst - es ist immer die gleiche Datenbasis unten drunter.
Wie oft willst du die Daten einer Tabelle denn speichern? Nein, wenn du in einer View die Daten änderst, werden die Daten natürlich in die entsprechenden Tabellen geschrieben. Eine View kann keine Daten speichern, weil eine View ist eine Projektion/Selektion auf n Tabellen.
Musst jetzt keine Wortklauberei betrieben. ZF_SAPler hatte nur geschrieben, dass es keine Z-Tabelle ist. Dass du daraus dann SAP-Namensraum ableitest hat er sicher nicht gewollt. Sein Problem ist einfach, dass die Tabelle nicht in "seinem" Namensraum liegt und dabei ist es unerheblich ob sie sich im SAP-Namensraum oder in einem reservierten Namensraum befindet.ralf.wenzel hat geschrieben: ↑06.05.2022 14:15Hmmm, lass mich doch mal überlegen, wie diese Namensräume heißen....
Für SAP ist jeder, der eine SAP-Lizenz besitzt ein Kunde - auch jemand, der Add-Ons entwickelt. Demzufolge ist jemand, der sich einen Namensraum reserviert, auch ein Kunde, weil die Voraussetzung dafür eine SAP-Lizenz ist. Wenn also ein Kunde einen Namensraum reserviert, dann ist das folglich ein Kundennamensraum.
Warum das wichtig ist: Die SAP bietet z. B. keine Gewährleistung im Kundennamensraum. Auch nicht, wenn dieser gar nicht DEM Kunden gehört, für den der Entwickler arbeitet.
Ralf
Jo, das ist richtig. Das gilt allerdings auch für reservierte Namensräume von Lieferanten von SAP-AddOns.ralf.wenzel hat geschrieben: ↑06.05.2022 14:30Das ist sogar ganz erheblich. Weil: Wenn man im SAP-Namensraum herumpfuscht, gefährdet man die Gewährleistung für u. U. weite Teile der SAP-Installation. Darum ist es relevant, ob SAP-Namensraum oder nicht. Das kann ganz, ganz, GANZ erhebliche Konsequenzen haben, wenn mal was nicht funktioniert und die SAP die Hände hebt und sagt "wir schreiben dir dann eine Rechnung, weil Entwickler X nämlich daran rumgespielt hat".
Ralf