QUERY aktualisieren

[E305GL]

"E305 GL"?
Nun ja, unter E305 finde ich einen Lautsprecher.

Aber solche mehr massiven Änderungen schafft E305GL doch wohl locker mit einem Soft-Handgriff.
Tut mir (nicht) Leid wegen der kleinen Spitze;-).

Es ist doch irgendwie sehr witzig wie (sogenannte) IT-Fachleute ohne Kenntnis von Fakten versuchen, aus welchen Gründen auch immer, moderne Sichtweisen abschätzig zu beurteilen.
Ich haben schon mehrmals diesem Forum eine E30-Demo angeboten um Euch die Möglichkeit einer professionellen Beurteilung und Horizonterweiterung zu geben.
Auf Grund der gegebenen Postings/Literaturhinweise/Links/etc ist es einem (Content_Admin) bedauerlicher Weise nicht möglich uns aufzufinden, siehe www.emsenhuber.at ??? Wenn BenderD meint unsere Argumentationen seien nur Geschwätz so verweise ich Ihn auf unsere Hompage und somit auf unsere Referenzkunden die E30 teilw. mehre Jahrzenhnte im Einsatz haben. Auf Anfrage Stellen wir gerne die Kontakte zu diesen IT-Entscheidungsträgern her.
Nun zum eigentlichen Ursprungsthema QUERY aktualisieren:
Uns stellt sich die Frage warum gibt es überhaupt 2.000 Queries, was machen die, sind es klassische Abfragen/Listen/Dateiausgaben/etc ? Wodurch unterscheiden sie sich ?
Ein Migrationsbeispiel: Ein Kunde hat 10 Firmen zu je 10 Filialen ergibt 100 Mandanten-Queries.
Unter E30 definieren wir nur 1 E30-Query. E30 erkennt den ausgewählten Mandanten, ordnet zur Laufzeit Bibliothek/Datei/Selektionskriterien zu bzw. konsulitert. Übernimmt u.A. auch Selektionskriteren die durch Fremdprogramme bereitgestellt wurden und arbeitet diese automatisch, wahlweise auch zeitgesteuert ab. E30 Unterstützt neben Einfachlisten auch hochkomplexe Druck- und Dateiausgabe (Faktura, Zahlschein etc. PDF, eMailversand). Nachdem die Anzahl der Queries um 99% vermindert, die Funktionalität entscheidet erhöht wurde sieht die Kalkulation einer E30-Migration wohl anders und somit leistbar aus, oder...!!!
Bitte argumentiert mit Fakten und nicht mit Sprüchen die geeignet sind Eure Fachkompetenz in Zweifel zu ziehen. Natürlich verstehen wir auch Spaß, siehe IT-Karrikaturen auf unserer Homepage.

[Fuerchau]

Alles gut und schön, wenn alle Mandanten dieselben Abfragen mit nur unterschiedlichen Selektionen benötigen.
Ebenso gibt es eben auch Anforderungen, dass vielleicht jeder Mitarbeiter eigene Queries bauen kann, den Query/400 ist dem Enduser eben auch zugänglich.
Da ist der Wildwuchs geradezu vorprogrammiert.

Auch wenn ich mehrere Mandanten auf einem System habe, heißt es ja nicht, dass jeder Mandant dieselben Auswertungen haben will.
Daher ist es für mich nicht vorstellbar, wie du genau nur 1 Query für alle Mandanten und User bereitstellen willst.
- Umsatzliste, Inland/Ausland mal mit oder ohne Währung
- Auftragsbestandsliste ebenso, je Abteilung mit unterschiedlicher feldauswahl
- Fertigungsliste
- Bedarfsplanung
- u.v.m.

Ideen gibts da zuhauf;-).

[Robi]

Er schreibt vom E30-Query!
D.h. sein Produkt hat, wie viele gute WaWi Systeme, eine eigene Möglichkeit abfragen zu erstellen.
Da ist es nix besonderes, das so zu gestalten, das Dateiänderungen egal sind oder sich automatisch anpassen, je nach gewählter Technik.
Das hier vom OS400 query und nicht von einem E30-Query geschrieben wird, ignoriert er in der Überzeugung, dass sein query dem des Os400 überlegen ist. Kann ja stimmen. Hilft hier nur, wieder Mal, nicht.

...

[Fuerchau]

Es geht ja darum, 2000 Queries auch mal so eben mit E30 ablösen zu können;-).
Aber trotzdem wird er auch mit seinem Produkt eine Vielzahl von Abfagen für seine Kunden bereitstellen können.

Beim Query/400 ist das nun mal so, dass es vor SQL bereits existierte und daher die Datei-ID's mit übernommen hat. Dies führt halt zu obigem Problem.

[BenderD]

Er schreibt vom E30-Query!
D.h. sein Produkt hat, wie viele gute WaWi Systeme, eine eigene Möglichkeit abfragen zu erstellen.
Da ist es nix besonderes, das so zu gestalten, das Dateiänderungen egal sind oder sich automatisch anpassen, je nach gewählter Technik.
Das hier vom OS400 query und nicht von einem E30-Query geschrieben wird, ignoriert er in der Überzeugung, dass sein query dem des Os400 überlegen ist. Kann ja stimmen. Hilft hier nur, wieder Mal, nicht.

...

... auch das ist ja nur zum Teil richtig. Wenn ich zum Beispiel ein Textfeld verlängere, passt es nicht mehr auf Reports, wenn ich den Typ eines Schlüsselfeldes ändere, ändern sich join Beziehungen, wenn ich ein Feld oder mehrere, dahin schiebe, wo sie hingehören (Lieferant aus Artikel auskoppeln), kriege ich das nicht immer in einer View weg...
Zudem verhindert ja keine Software, dass daneben noch weitere Reports außerhalb der Software angelegt werden, was in den angefragten Fällen wohl das primäre Problem ist.
Was 5GL etc. angeht, verlasse ich mich auf die Einschätzungen der Wissenschaft, die da Informatik heißt. Ich habe ja nix gegen gesundes Selbstvertrauen, aber durchaus was gegen uferlose Marketing-Sprüche.

D*B

[camouflage]

Es ist doch irgendwie sehr witzig wie (sogenannte) IT-Fachleute ohne Kenntnis von Fakten versuchen, aus welchen Gründen auch immer, moderne Sichtweisen abschätzig zu beurteilen.

Bitte argumentiert mit Fakten und nicht mit Sprüchen die geeignet sind Eure Fachkompetenz in Zweifel zu ziehen. Natürlich verstehen wir auch Spaß, siehe IT-Karrikaturen auf unserer Homepage.

Es reicht jetzt. Es nervt nur noch. Dass man sein Produkt vertritt ist eine legitime Sache, aber schlussendlich bis zum verunglimpfen - das geht nicht. Blacklist!

Viele hier sind froh um Hilfestellungen und versuchen auch eigenes Wissen einzubringen. Davon lebt das Forum. Aber dieses penetrante Marketinggedöns muss jetzt nicht sein. Die Anfragen drehen sich um die Bordmittel der IBM i. Vielleicht wäre es besser, statt hier rumzutrollen, mal die eigene Webseite zu aktualisieren/modernisieren.

Abgesehen davon, Dieter hat völlig Recht.

[Fuerchau]

Nunja, mit SAP ist ja auch alles möglich, sogar Berichte aller Art, Datawarehouse (BW) u.v.m.
Trotzdem dauern Migrationen u.U. mehrere Jahre und kosten ein Vermögen.
Und nicht allzu selten werden sie auch wieder eingestellt.

Ich selber bin auch bei einem Kunden an Schnittstellen zu einem Oracle-ERP beteiligt.
Die Aktion läuft nun mittlerweile gut 15 Jahre, die Logistik (Lager, Auslieferung) verbleibt auf der IBM i.
Die Kosten will wohl keiner genau wissen;-).
Das Reporting (FTIS-BI) ist ebenso "aus dem Ruder gelaufen", da jede Abteilung ihre eigenen Dashboards benötigte (und bekam) und wird deshalb nun in einem Kraftakt konsolidiert, also neu aufgebaut.
Zeitbedarf auch hier ca. 50 Manntage, und wir kennen die Berichte.

[E305GL]

Nunja, mit SAP ist ja auch alles möglich, sogar Berichte aller Art, Datawarehouse (BW) u.v.m.
Trotzdem dauern Migrationen u.U. mehrere Jahre und kosten ein Vermögen.
Und nicht allzu selten werden sie auch wieder eingestellt.

Ich selber bin auch bei einem Kunden an Schnittstellen zu einem Oracle-ERP beteiligt.
Die Aktion läuft nun mittlerweile gut 15 Jahre, die Logistik (Lager, Auslieferung) verbleibt auf der IBM i.
Die Kosten will wohl keiner genau wissen;-).
Das Reporting (FTIS-BI) ist ebenso "aus dem Ruder gelaufen", da jede Abteilung ihre eigenen Dashboards benötigte (und bekam) und wird deshalb nun in einem Kraftakt konsolidiert, also neu aufgebaut.
Zeitbedarf auch hier ca. 50 Manntage, und wir kennen die Berichte.

Unterstreiche voll und ganz Deine Argumentation. Habe mich seinerzeit IBM370 SAP R1 mit der Offenheit und Komplexität auseinandergesetzt. Eigene Assenblerprogramme hineingehängt. Habe all zu viele SAP-Projekte "sterben" gesehen. U.A. auch aus diesen Erfahrungen haben wir gelernt und E30 mit der entsprechenden Flexibilität und "Kundenfreundlichkeit" ausgestattet. Einen gravierenden Nachteil hat E30: (Berater-)Unsummen à la SAP kann man nicht verdienen, geht ja vieles "easy of use" und ressourcensparend. Nachdem die "Meldungen" im Forum sehr vage formuliert sind und eine Aufblähung der eigentlichen Thematik zu Folge hat möchte ich innerhalb dieses Themas keine weiteren Stellungnahmen mehr kommentieren. Wen es Spass macht der kann weiterhin gerne Äpfel mit Birnen vergleichen.

[hel400]

--------------------