Updates
Moderator: SYNERPY
- 
				segelfreak
- Beiträge: 72
- Registriert: Mo Jun 27, 2005 10:01 am
Updates
Hallo an Alle,
wir setzen nun schon seit einigen Jahren AvERP erfolgreich in userem Unternehmen ein.
Leider waren unsere Versuche, mit den Update paketen zu 99,- das System auf dem laufenden Stand zu halten ziemlich erfolglos. Und jetzt gibt es sie ganz und gar nicht mehr.
Es bleibt nur noch die Wahl zwischen neuer Version ohne Datenübernahme oder einem Update durch Synerpy, welches sicher von den Kosten her im Rahmen bleibt, aber auch nicht jedermanns Sache ist.
Ich möchte jetzt nicht den Spielverderber machen, aber ich bin gerade beim stöbern bei den FAQ's über diese Passage gestolpert:
Was kosten Updates?
Updates sind, genau wie die Hauptprogramme und alle Module und Datenbanken, kostenlos erhältlich.
Aha! Nur, wie ist das jetzt genau gemeint?
Die Bereitstellung einer neuen Version ist ja im eigentlichen Sinne kein Update.
Wie darf ich mir ein kostenloaes Update nach o.g. Verweis denn vorstellen?
Früher gab es noch update scripte zum downloaden, aber diese kann ich schon seit einiger Zeit nicht mehr finden.
Für eine Klärung bedanke ich mich schon jetzt einmal recht herzlich!
segelfreak
			
			
									
						
										
						wir setzen nun schon seit einigen Jahren AvERP erfolgreich in userem Unternehmen ein.
Leider waren unsere Versuche, mit den Update paketen zu 99,- das System auf dem laufenden Stand zu halten ziemlich erfolglos. Und jetzt gibt es sie ganz und gar nicht mehr.
Es bleibt nur noch die Wahl zwischen neuer Version ohne Datenübernahme oder einem Update durch Synerpy, welches sicher von den Kosten her im Rahmen bleibt, aber auch nicht jedermanns Sache ist.
Ich möchte jetzt nicht den Spielverderber machen, aber ich bin gerade beim stöbern bei den FAQ's über diese Passage gestolpert:
Was kosten Updates?
Updates sind, genau wie die Hauptprogramme und alle Module und Datenbanken, kostenlos erhältlich.
Aha! Nur, wie ist das jetzt genau gemeint?
Die Bereitstellung einer neuen Version ist ja im eigentlichen Sinne kein Update.
Wie darf ich mir ein kostenloaes Update nach o.g. Verweis denn vorstellen?
Früher gab es noch update scripte zum downloaden, aber diese kann ich schon seit einiger Zeit nicht mehr finden.
Für eine Klärung bedanke ich mich schon jetzt einmal recht herzlich!
segelfreak
- 
				miboe
- Beiträge: 1295
- Registriert: Fr Jul 28, 2006 9:13 am
Ich verfolge Averp nun auch schon seit Version 2005 und muß sagen, daß ich angesichts der großen Sprünge seit Version 2008 mir überhaupt nicht vorstellen kann, wie das noch mit Skriptpaketen gehen soll. Schon gar nicht in einer modifizierten Umgebung mit Kundenanpassungen.
Ich erinnere mich an meine Versuche, eine 2005 per Skriptpaket auf eine 2006er zu bringen. Die Änderungen waren verglichen etwa mit 2008 nach 2009 (geschweige denn 2006 nach 2008) eher SEHR klein und trotzdem war das Skriptpaket eine echte Herausforderung.
Gerade für eine Umgebung, die Kundenanpassungen enhält, gibt es aber eine sehr elegante Möglichkeit, ein Update selbst zu machen: man nehme
* die neue LEERE Datenbank von Averp
* eine Kopie der eigenen Datenbank
* eine IBexpert Vollversion, wobei die kleinste davon ausreicht
Mit diesen "Zutaten" kann man dann ein Strukturupdate fahren, wobei die Quelle die neue und das Ziel die eigene Datenbank ist. IBexpert ERZEUGT dann quasi das, was man früher von Synerpy als updatepaket bekommen hat. Aber halt maßgeschneidert auf die eigenen bedürfnisse.
Gruß
Michael
			
			
									
						
							Ich erinnere mich an meine Versuche, eine 2005 per Skriptpaket auf eine 2006er zu bringen. Die Änderungen waren verglichen etwa mit 2008 nach 2009 (geschweige denn 2006 nach 2008) eher SEHR klein und trotzdem war das Skriptpaket eine echte Herausforderung.
Gerade für eine Umgebung, die Kundenanpassungen enhält, gibt es aber eine sehr elegante Möglichkeit, ein Update selbst zu machen: man nehme
* die neue LEERE Datenbank von Averp
* eine Kopie der eigenen Datenbank
* eine IBexpert Vollversion, wobei die kleinste davon ausreicht
Mit diesen "Zutaten" kann man dann ein Strukturupdate fahren, wobei die Quelle die neue und das Ziel die eigene Datenbank ist. IBexpert ERZEUGT dann quasi das, was man früher von Synerpy als updatepaket bekommen hat. Aber halt maßgeschneidert auf die eigenen bedürfnisse.
Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
			
						--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
- 
				Geri12
- Beiträge: 589
- Registriert: Mi Apr 16, 2008 7:51 am
Hallo Michael,
ich überlege auch schon seit einer Ewigkeit daran herum, wie wir ohne ein Chaos zu verursachen auf eine neue Version von AvERP updaten könnten ...
Die Idee mit dem Datenbankstrukturvergleich (hier ist doch der IBExpert-Menüpunkt 'Datenbankstrukturvergleich' gemeint, oder?) hatte ich diesbezüglich auch schon. Allerdings habe ich das Ergebnis dieses Vergleichs so bewertet, dass bei geändertem Quellcode immer der Quellcode in der Ziel-Datenbank von dem der Quell-Datenbank überschrieben wird. Habe ich also Prozedur XYZ für uns weiterentwickelt und Synerpy ebenfalls an Prozedur XYZ weiterentwickelt, würde dann bei einem Strukturvergleich IBExpert das Änderungescript nicht so gestalten, dass meine Prozedur komplett überschrieben würde ?
Allerdings könnte man so herausbekommen, welche Prozeduren verändert wurden, um die neuen evt. per Hand um die eigenen Änderungen zu erweitern. Wäre allerdings eine enorme Fleißarbeit.
Wie würde man bei neuen Tabellenfeldern vorgehen ? Vor dem Strukturvergleich erst die eigenen neuen Felder in die neue AvERP-Version einspielen ?
Zudem bleiben noch die enormen Änderungen an den einzelnen Masken und Reporten. Und da habe ich keine Idee, wie man hier ein Update durchführen könnte.
Hast Du schon mal per Hand eine Euerer Datenbanken über IBExpert geUPDATEd ?
			
			
									
						
							ich überlege auch schon seit einer Ewigkeit daran herum, wie wir ohne ein Chaos zu verursachen auf eine neue Version von AvERP updaten könnten ...
Die Idee mit dem Datenbankstrukturvergleich (hier ist doch der IBExpert-Menüpunkt 'Datenbankstrukturvergleich' gemeint, oder?) hatte ich diesbezüglich auch schon. Allerdings habe ich das Ergebnis dieses Vergleichs so bewertet, dass bei geändertem Quellcode immer der Quellcode in der Ziel-Datenbank von dem der Quell-Datenbank überschrieben wird. Habe ich also Prozedur XYZ für uns weiterentwickelt und Synerpy ebenfalls an Prozedur XYZ weiterentwickelt, würde dann bei einem Strukturvergleich IBExpert das Änderungescript nicht so gestalten, dass meine Prozedur komplett überschrieben würde ?
Allerdings könnte man so herausbekommen, welche Prozeduren verändert wurden, um die neuen evt. per Hand um die eigenen Änderungen zu erweitern. Wäre allerdings eine enorme Fleißarbeit.
Wie würde man bei neuen Tabellenfeldern vorgehen ? Vor dem Strukturvergleich erst die eigenen neuen Felder in die neue AvERP-Version einspielen ?
Zudem bleiben noch die enormen Änderungen an den einzelnen Masken und Reporten. Und da habe ich keine Idee, wie man hier ein Update durchführen könnte.
Hast Du schon mal per Hand eine Euerer Datenbanken über IBExpert geUPDATEd ?
Gruß
Geri12
Software-Version: V4.2.5.2
FDB-Version: AvERP2008-A.14
			
						Geri12
Software-Version: V4.2.5.2
FDB-Version: AvERP2008-A.14
- 
				miboe
- Beiträge: 1295
- Registriert: Fr Jul 28, 2006 9:13 am
Ich fange mal von hinten an: Änderungen an Reports und Masken sind aus Sicht von Firebird normale Daten und bleiben bei einem Strukturupdate erhalten. Schau mal in die Tabelle A_MASKEN, da steht die Definition der Maske in einem Datenfeld drin ... Änderungen an den Views werden vom Strukturupdate gemacht.
Der Rest der Ausführungen ist im großen und ganzen korrekt und ja, es ist eine verdammte Fleißarbeit ... ABER: das wäre ein Updatepaket aus Skripten auch. Ich habe derzeit nur den private IBExpert, mit dem ich keinen Zugriff auf den Strukturvergleich mehr habe, aber ich erinnere mich düster, daß man da Bereich auswählen konnte, welche man bearbeiten will. Damit könnte man das ganze übersichtlich halten. Also z.B. erst alle DOMAINS, dann alle TABLES, danach alle VIEWS usw. Das schöne: man kann die Skripte, die der IBexpert generiert, wenn Sie funktioniert haben speichern, und dann ein zweites Mal auf die LIVE-Datenbank anwenden.
Die SYN's und ADMIN's wissen dazu sicher mehr Details ...
Gruß
Michael
			
			
									
						
							Der Rest der Ausführungen ist im großen und ganzen korrekt und ja, es ist eine verdammte Fleißarbeit ... ABER: das wäre ein Updatepaket aus Skripten auch. Ich habe derzeit nur den private IBExpert, mit dem ich keinen Zugriff auf den Strukturvergleich mehr habe, aber ich erinnere mich düster, daß man da Bereich auswählen konnte, welche man bearbeiten will. Damit könnte man das ganze übersichtlich halten. Also z.B. erst alle DOMAINS, dann alle TABLES, danach alle VIEWS usw. Das schöne: man kann die Skripte, die der IBexpert generiert, wenn Sie funktioniert haben speichern, und dann ein zweites Mal auf die LIVE-Datenbank anwenden.
Die SYN's und ADMIN's wissen dazu sicher mehr Details ...
Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
			
						--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
- 
				Geri12
- Beiträge: 589
- Registriert: Mi Apr 16, 2008 7:51 am
Hallo
@Michael
Sorry, gerade was die Masken und Reports anbetrifft habe ich mich wohl äußerst ungünstig ausgedrückt. Ich weiß, dass diese Elemente in der Datenbank abliegen in einem Feld der Tabelle A_MASKEN. Mein Gedanke bzgl. der Updates bezog sich darauf, dass ein nicht gerade unbedeutender Teil der Programmlogik in den Maskenscripten untergebracht ist. Von daher werden diese von Synerpy auch kräftig überarbeitet und weiterentwickelt. Wenn ich nun unsere Masken beibehalte ohne Maskenupdate, ginge mir die neu hinzugekommene Funktionalität (und auch die neu in die Tabellen und Masken aufgenommenen Felder) 'verloren'. Von daher wäre es gut, beide Scripte miteinander zu kombinieren. Und an dem Punkt komme ich ins Grübeln, wie das geschehen soll (OnCreate, OnChange, OnExit, ..., PROC0001-PROC0037, usw.).
Die Sache mit der Unmöglichkeit von Update-Scripten würde ich genau so unterschreiben, das habe ich auch in einem anderen Thread schon geschrieben. Ich habe hier z.B. noch ein Script zur Korrektur eines Bugs, welches ich noch nicht eingespielt habe. Ich brauche einfach eine gewisse Zeit, um überprüfen zu können, welche Zeilen dieses Bugfix-Scripts bei uns eingepflegt werden müssen und welche Zeilen zum Versions-Update gehören. (Ich gehe davon aus, dass der Bug in der damals gerade aktuellen Datenbank beseitigt wurde und dieser entsprechend überarbeitete Quellcode an mich weitergereicht wurde.) Und das ist jetzt nur ein einziges Script, für das ich im Moment nicht die Zeit finde. Also von daher kann ich mir das bei kundenspezifisch geänderten Datenbanken absolut nicht vorstellen.
@PaGL
Hier würde ich wie schon von Michael angesprochen versuchen, die Scripte nach und nach einzuspielen. Die entspr. Fehlermeldung sollte eigentlich auch schon einen Hinweis darauf bieten, wo es denn nun hängt. Und ich denke, die Reihenfolge der Einspielung der Scripte ist hier ganz entscheidend. Ist z.B. ein neues Tabellenfeld beim Update hinzugekommen, so muss vor der Änderung der View zuerst die Tabelle erweitert werden.
			
			
									
						
							@Michael
Sorry, gerade was die Masken und Reports anbetrifft habe ich mich wohl äußerst ungünstig ausgedrückt. Ich weiß, dass diese Elemente in der Datenbank abliegen in einem Feld der Tabelle A_MASKEN. Mein Gedanke bzgl. der Updates bezog sich darauf, dass ein nicht gerade unbedeutender Teil der Programmlogik in den Maskenscripten untergebracht ist. Von daher werden diese von Synerpy auch kräftig überarbeitet und weiterentwickelt. Wenn ich nun unsere Masken beibehalte ohne Maskenupdate, ginge mir die neu hinzugekommene Funktionalität (und auch die neu in die Tabellen und Masken aufgenommenen Felder) 'verloren'. Von daher wäre es gut, beide Scripte miteinander zu kombinieren. Und an dem Punkt komme ich ins Grübeln, wie das geschehen soll (OnCreate, OnChange, OnExit, ..., PROC0001-PROC0037, usw.).
Die Sache mit der Unmöglichkeit von Update-Scripten würde ich genau so unterschreiben, das habe ich auch in einem anderen Thread schon geschrieben. Ich habe hier z.B. noch ein Script zur Korrektur eines Bugs, welches ich noch nicht eingespielt habe. Ich brauche einfach eine gewisse Zeit, um überprüfen zu können, welche Zeilen dieses Bugfix-Scripts bei uns eingepflegt werden müssen und welche Zeilen zum Versions-Update gehören. (Ich gehe davon aus, dass der Bug in der damals gerade aktuellen Datenbank beseitigt wurde und dieser entsprechend überarbeitete Quellcode an mich weitergereicht wurde.) Und das ist jetzt nur ein einziges Script, für das ich im Moment nicht die Zeit finde. Also von daher kann ich mir das bei kundenspezifisch geänderten Datenbanken absolut nicht vorstellen.
@PaGL
Hier würde ich wie schon von Michael angesprochen versuchen, die Scripte nach und nach einzuspielen. Die entspr. Fehlermeldung sollte eigentlich auch schon einen Hinweis darauf bieten, wo es denn nun hängt. Und ich denke, die Reihenfolge der Einspielung der Scripte ist hier ganz entscheidend. Ist z.B. ein neues Tabellenfeld beim Update hinzugekommen, so muss vor der Änderung der View zuerst die Tabelle erweitert werden.
Gruß
Geri12
Software-Version: V4.2.5.2
FDB-Version: AvERP2008-A.14
			
						Geri12
Software-Version: V4.2.5.2
FDB-Version: AvERP2008-A.14
- 
				miboe
- Beiträge: 1295
- Registriert: Fr Jul 28, 2006 9:13 am
Achso ... aber auch dafür gibt es eine Lösung mit zwei Möglichkeiten:
Version 1 (Blut, Schweiß und Tränen ): Die Masken der neuen Version einmal mit dem Designer öffnen, als *.res speichern und dann die *.res in eure Datenbank einlesen ... dazu wäre das schon vielfach angeforderte Changelog eine wahnsinnige Hilfe, weil man nur die Masken anfassen muß, in denen sich was geändert hat.
 ): Die Masken der neuen Version einmal mit dem Designer öffnen, als *.res speichern und dann die *.res in eure Datenbank einlesen ... dazu wäre das schon vielfach angeforderte Changelog eine wahnsinnige Hilfe, weil man nur die Masken anfassen muß, in denen sich was geändert hat.
Version 2: mit dem IBexpert aus der Datenübersicht die Daten als Update-Befehl in den Scripteditor schreiben, dabei den MASKENKEY als Where Klausel, weil die IDs abweichen könnten. Diese Idee kann aber eventuell daran scheitern, daß die Maskendefinition in einem BLOB Feld steht ...
Ich habe hier im Moment gerade nur eine alte Designer Version. Ich muß zuhause auf dem Testrechner mal nachschauen, ob die neueste Designer-Version nicht sogar eine Möglichkeit hatte, alle Maske auf einen Schlag als *.res rauszuspeichern
Gruß
Michael
			
			
									
						
							Version 1 (Blut, Schweiß und Tränen
 ): Die Masken der neuen Version einmal mit dem Designer öffnen, als *.res speichern und dann die *.res in eure Datenbank einlesen ... dazu wäre das schon vielfach angeforderte Changelog eine wahnsinnige Hilfe, weil man nur die Masken anfassen muß, in denen sich was geändert hat.
 ): Die Masken der neuen Version einmal mit dem Designer öffnen, als *.res speichern und dann die *.res in eure Datenbank einlesen ... dazu wäre das schon vielfach angeforderte Changelog eine wahnsinnige Hilfe, weil man nur die Masken anfassen muß, in denen sich was geändert hat.Version 2: mit dem IBexpert aus der Datenübersicht die Daten als Update-Befehl in den Scripteditor schreiben, dabei den MASKENKEY als Where Klausel, weil die IDs abweichen könnten. Diese Idee kann aber eventuell daran scheitern, daß die Maskendefinition in einem BLOB Feld steht ...
Ich habe hier im Moment gerade nur eine alte Designer Version. Ich muß zuhause auf dem Testrechner mal nachschauen, ob die neueste Designer-Version nicht sogar eine Möglichkeit hatte, alle Maske auf einen Schlag als *.res rauszuspeichern
Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
			
						--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
- 
				Geri12
- Beiträge: 589
- Registriert: Mi Apr 16, 2008 7:51 am
Für diese Variante hat IBExpert schon das passende Tool parat: Menü 'Nützliches', Menüpunkt 'Tabellendatenvergleich' -> Erstellt ein Script, mit dem überflüssige Datensätze gelöscht, neue Datensätze angehängt und geänderte Datensätze geupdated werden. Funktioniert so wie es aussieht auch, wenn BLOB-Felder vorhanden sind.miboe hat geschrieben:Version 1 (Blut, Schweiß und Tränen): Die Masken der neuen Version einmal mit dem Designer öffnen, als *.res speichern und dann die *.res in eure Datenbank einlesen ... dazu wäre das schon vielfach angeforderte Changelog eine wahnsinnige Hilfe, weil man nur die Masken anfassen muß, in denen sich was geändert hat.
Aber ich merke, ich muß meine Worte noch präziser wählen: Ich spreche nicht von der RES-Maske als gesamtes, sondern von den in der Maske enthaltenen Objekten und Scripten.
Ich habe für uns die Adressmaske z.B. ergänzt um eine Schnellsuche und um Grids für Kunde, Lieferant, Vertreter, Ansprechpartner und Lief/Rech-Adressen. So sieht man direkt schon in der Adressmaske, mit welchem anderen Stammdatensatz diese Adresse verbunden ist. Wenn jetzt Synerpy die Adressmaske ihrerseits um eine Schnellsuche ergänzt, dann möchte ich trotzdem meine Grids nicht verlieren. Da nutzt es mir nichts, die Maske der neuen Version in meine Datenbank zu spielen.
Oder bei der Bestellposition habe ich in PROC0007 ergänzt, dass immer beim Anlegen überprüft wird, ob bei diesem Artikel BSA.AKTIV=N oder BSAL.L_STATUS=R steht und entspr. eine Abfrage implementiert, da der Artikel in diesem Fall nur noch in ausnahmsweise bestellt werden darf. Auf der anderen Seite hat Synerpy die Bestellpos.Maske evt. um andere Funktionalitäten erweitert in einer neuen PROC0099. Und DIESE Änderungen von beiden Seiten in eine einzige Maske zusammenfließen zu lassen, darum ging es in meinem Gedanken oben.

Gruß
Geri12
Software-Version: V4.2.5.2
FDB-Version: AvERP2008-A.14
			
						Geri12
Software-Version: V4.2.5.2
FDB-Version: AvERP2008-A.14
