Ich möchte hier mal eine Diskussion beginnen über die Dokumentation eigener Anpassungen.
Wer macht hier was und wie ?
Sind eigendefinierte Tabellen, Trigger und Prozeduren mit neuen Masken bzw. geändrten Masken und Änderungen im Quelltext mitgelieferter Programmteile nach einem Update immer noch verfügbar oder muss das alles mühevoll migriert werden?
Anpassungen
Moderator: SYNERPY
-
- Beiträge: 35
- Registriert: So Jan 23, 2005 1:35 pm
Re: Anpassungen
Hallo,
So wie ich das sehe wohl eher letzteres.Zwitsch hat geschrieben:Sind eigendefinierte Tabellen, Trigger und Prozeduren mit neuen Masken bzw. geändrten Masken und Änderungen im Quelltext mitgelieferter Programmteile nach einem Update immer noch verfügbar oder muss das alles mühevoll migriert werden?
Gruss
Break
|| Firebird 1.5 (Vers. WI-V6.3.2.4731), AvERP v1.5.0.11, GDB AvERP2005.A.11, W2K SP2 Server, XP Prof. SP1 Clients ||
Break
|| Firebird 1.5 (Vers. WI-V6.3.2.4731), AvERP v1.5.0.11, GDB AvERP2005.A.11, W2K SP2 Server, XP Prof. SP1 Clients ||
-
- Site Admin
- Beiträge: 2673
- Registriert: Di Feb 10, 2004 5:48 am
- Wohnort: Bayreuth
Das kann man ganz eindeutig beantworten: Das kommt ganz darauf an.
Wir unterscheiden hier zwischen firmenspezifischen Änderungen und Dingen, die auch für andere Unternehmen interessant sind.
Werden bestehende Trigger und Prozeduren angepasst, so sind diese Änderungen weg, wenn wir die Trigger auch angepasst haben. Logisch.
Hier gibt es zwei Wege das zu umgehen:
1. Uns die Änderung mitteilen. Ist sie für die Allgemeinheit interessant, dann werden wir sie in den Standard übernehmen. Hilft das nicht, dann
2. Eigene Trigger und Prozeduren reinbauen. Diese werden von uns nicht überschrieben (wenn die Trigger-Stelle hoch genug ist).
3. Sonst die Änderungen einfach mitdokumentieren und nach jedem Update nachpflegen. Das ist aber nur in den allerseltensten Fällen notwendig.
Bei Tabellen verhält es sich schon SEHR viel anders.
Das intere System von AvERP basiert darauf, dass Tabellen (dazu gehören intern auch Views und UP_ bzw. ZP_ Prozeduren) eine feste ID haben, die bei jeder Firma identisch ist. Das macht Updates erst möglich, da sonst Rechte, Menüsortierung etc. nicht möglich wären. Diese ID wird fest von uns vergeben.
Wiederum zwei Möglichkeiten:
1. Uns benachrichtigen, was hinzugefügt werden soll. Tabellen und Felder. Diese sichten wir, korrigieren gegebenenfalls und vergeben dann eine ID. Bedingung ist, dass alles in AvERP aufgenommen wird.
2. Handelt es sich um eine firmenspezifische Änderung, die wir nicht in den Standard übernehmen werden, so sollte als Tabellen-ID eine gewählt werden, die wir so schnell nicht erreichen (so ab 10.000.000, in 1000er Schritten!).
Wir unterscheiden hier zwischen firmenspezifischen Änderungen und Dingen, die auch für andere Unternehmen interessant sind.
Werden bestehende Trigger und Prozeduren angepasst, so sind diese Änderungen weg, wenn wir die Trigger auch angepasst haben. Logisch.
Hier gibt es zwei Wege das zu umgehen:
1. Uns die Änderung mitteilen. Ist sie für die Allgemeinheit interessant, dann werden wir sie in den Standard übernehmen. Hilft das nicht, dann
2. Eigene Trigger und Prozeduren reinbauen. Diese werden von uns nicht überschrieben (wenn die Trigger-Stelle hoch genug ist).
3. Sonst die Änderungen einfach mitdokumentieren und nach jedem Update nachpflegen. Das ist aber nur in den allerseltensten Fällen notwendig.
Bei Tabellen verhält es sich schon SEHR viel anders.
Das intere System von AvERP basiert darauf, dass Tabellen (dazu gehören intern auch Views und UP_ bzw. ZP_ Prozeduren) eine feste ID haben, die bei jeder Firma identisch ist. Das macht Updates erst möglich, da sonst Rechte, Menüsortierung etc. nicht möglich wären. Diese ID wird fest von uns vergeben.
Wiederum zwei Möglichkeiten:
1. Uns benachrichtigen, was hinzugefügt werden soll. Tabellen und Felder. Diese sichten wir, korrigieren gegebenenfalls und vergeben dann eine ID. Bedingung ist, dass alles in AvERP aufgenommen wird.
2. Handelt es sich um eine firmenspezifische Änderung, die wir nicht in den Standard übernehmen werden, so sollte als Tabellen-ID eine gewählt werden, die wir so schnell nicht erreichen (so ab 10.000.000, in 1000er Schritten!).
-
- Beiträge: 35
- Registriert: So Jan 23, 2005 1:35 pm
Hallo Admin,
Wäre es nicht eine Idee einen bestimmten ID-Bereich generell für Anwenderspezifische Tabellen zu reservieren? Dann bräuchte sich der Anwender keine Gedanken darum zu machen und ihr auch nicht.admin hat geschrieben: Bei Tabellen verhält es sich schon SEHR viel anders.
...
2. Handelt es sich um eine firmenspezifische Änderung, die wir nicht in den Standard übernehmen werden, so sollte als Tabellen-ID eine gewählt werden, die wir so schnell nicht erreichen (so ab 10.000.000, in 1000er Schritten!).
Gruss
Break
|| Firebird 1.5 (Vers. WI-V6.3.2.4731), AvERP v1.5.0.11, GDB AvERP2005.A.11, W2K SP2 Server, XP Prof. SP1 Clients ||
Break
|| Firebird 1.5 (Vers. WI-V6.3.2.4731), AvERP v1.5.0.11, GDB AvERP2005.A.11, W2K SP2 Server, XP Prof. SP1 Clients ||
Anpassungen
Eigene Trigger verwenden und die vorhandenen nicht ändern, das klinngt gut. Wie hoch sollte die Triggerstelle angesiedelt werden, damit es keinen Konflikt gibt ?
Der nächste Punkt für Änderungen betrifft Sourcen in den Masken. Kann man hier auch eigene Programmteile einem bspw. Button zuordnen, der breits einen Programmteil von AvERP hat. Mit einem INCLUDE-Befehl oder so was ähnlichem.
Gibt es die Möglichkeit, alle Maskenquelltexte ohne Aufruf den Maskendesigners in einem Editor anzuschauen bzw. zu editieren ?
Der nächste Punkt für Änderungen betrifft Sourcen in den Masken. Kann man hier auch eigene Programmteile einem bspw. Button zuordnen, der breits einen Programmteil von AvERP hat. Mit einem INCLUDE-Befehl oder so was ähnlichem.
Gibt es die Möglichkeit, alle Maskenquelltexte ohne Aufruf den Maskendesigners in einem Editor anzuschauen bzw. zu editieren ?
-
- Beiträge: 216
- Registriert: Do Jun 17, 2004 8:08 am
Re: Anpassungen
Die höchste Trigger-Position liegt zur Zeit bei 5. Ich denke wenn man einen Trigger ab Position 10 verwendet, sollte er zu 99,9% sicher seinzwitsch hat geschrieben:Eigene Trigger verwenden und die vorhandenen nicht ändern, das klinngt gut. Wie hoch sollte die Triggerstelle angesiedelt werden, damit es keinen Konflikt gibt ?
Sie können Prozeuren in der Maske anlegen und diese auch mit einem "Include(PROCxxxx)" aufrufen. Diese Prozedur ist dann in der gesamten Maske verfügbar. Jedoch nicht in anderen Masken. Ein Beispiel für diesen Aufruf findet man in den meisten "Kopfmasken" (FRMV_BAUF, FRMV_BRRC,FRMV_BFA,...).zwitsch hat geschrieben:Der nächste Punkt für Änderungen betrifft Sourcen in den Masken. Kann man hier auch eigene Programmteile einem bspw. Button zuordnen, der breits einen Programmteil von AvERP hat. Mit einem INCLUDE-Befehl oder so was ähnlichem.
Der Quelltext liegt im RES-Format in der Datenbank. In der Tabelle A_MASKEN. Mit einer Prozedur, die die BLOB-Felder ausliest, sollte man relativ schnell an die Informationen kommen.[/quote]zwitsch hat geschrieben:Gibt es die Möglichkeit, alle Maskenquelltexte ohne Aufruf den Maskendesigners in einem Editor anzuschauen bzw. zu editieren ?