Was ich noch loswerden wollte...

[Fuerchau]

Das ist eben genau das, was auch andere, zumindest in Deutschland, eben genauso betreiben.
Softwareablösungen dauern durchaus mehrere Jahre und trotzdem geht die Entwicklung durchaus noch weiter.
Aber ERP-Hersteller, mit denen ja alles anfing, sind leider größtenteils abgewandert. So hat man eben noch viele Altsysteme im Weiterbetrieb.
Z.T. aber auch nur noch wegen der Bereitschaft noch mindestens 10 Jahre die Daten aufheben zu müssen und jedem Betriebsprüfer oder Finanzamtsmitarbeiter die Möglichkeit zu schaffen, noch mal nachsehen zu können.
So gibts dann Übergangslösungen, Schnittstellen u.v.m., bis dann die neue Welt endlich fertig ist.
U.U. setzt man das dann doch wieder in den Sand, weil man sich verspekuliert hat und das das so nicht geht. Es gibt genug Beispiel z.B. auch von SAP, wo die Ablösung letztlich scheitert.
Was ja eigentlich für die IBM spricht.

Aber, wie Birgitta sohl schon des öfteren gesagt hat, scheint diese Stimmung nur Deutschland zu betreffen.

Auch ich bin, bis auf einen letzten Kunden, von der IBM weg und wir haben unser BI-System auf Basis C#.Net, Windows und Firebird aufgesetzt. Mit Erfolg natürlich;-).

[camouflage]

Hallo Baldur,
ist in der Schweiz genau so, wenn nicht sogar schon weiter. Es werden auf RPG Basis einfach keine neuen Lösungen mehr produziert. Ich hänge die mal an einem Versäumnis seitens IBM auf das schon zu AS400 Zeiten gemacht wurde und nie korrigiert wurde. Nämlich eine Entwicklungsumgebung für grafische Oberflächen zur Verfügung zu stellen. Das OS/2 Visual RPG war ja mehr ein schlechter Witz, obwohl es in die richtige Richtung gegangen wäre. So bleibt wohl nur noch ein Abgesang über.

Nur nicht überall schickt man die IBM i über Bord. In Italien z.B. herrscht noch eine grosse Zustimmung, inkl. einer breiten Palette an Anwendungen.

Noch etwas Baldur, wie ich sehe, ist aber auch Power BI ein Thema bei euch ;-).
(welches wunderbar mir der ODBC Schnittstelle zur IBM i interagiert)

[Fuerchau]

Power BI ist aktuell kein Thema, da wir mit unserer Lösung OnPremise durchaus vergleichbar sind.
Es gibt zwar einen DB2-Treiber für Power-BI, allerdings unterstützt dieser wohl die DB2 for i nicht. Es gibt da keinen Hinweis auf einen Connectionstring und wie der auszusehen hat.
Mit native ODBC habe ich aber gerade bei Power BI eher massive Schwierigkeiten.
Bei Tabellen, bei denen die Feldnamen alle aus Großbuchstaben bestehen, gibts tatsächlich Möglichkeiten.
Allerdings gehen wir vermehrt auch bei der IBM i hin zu Namen in Groß/Kleinschreibung, im RPGLE dann via ALIAS. Funktioniert soweit super, nur das Power BI das nicht uterstützt.

Mircrosoft hat über die Jahrzehnte hinweg sich dem SQL-Standard verweigert, dass Tabellennamen und Spaltennamen auch in Anführungszeichen verwendbar sind.
Microsoft beharrt hier stur auf seinen eckigen Klammern, die es schon in Access gab.
Daher gibt mir Power BI die Meldung, dass keine Informationen zu ggf. Tabellen, aber auch nicht zu Spalten verfügbar sind. Und mit den autogenerierten Feldnamen (10-Stellig) will ich nicht arbeiten.
Also muss ich eine native SQL selber schreiben und zwar ohne jedwede grafische Uterstützung.

Klar könnte ich mit den Kurznahmen arbeiten, dann muss ich allerdings jedes Feld im Power BI individuell mit einem Titel bearbeiten. Und dies mit jedem neuen Dokument immer und immer wieder.

Hinzu kommt, dass mit ODBC viele Funktionen dann nicht unterstütz werden, zumindest nicht komfortabel. Versuche mal eine Abfrage mit einem Parameter im SQL, den ich im Power BI ja definieren kann.

Wie stehts mit DirectQuery für die so favorisierten Echtzeit-Abfragen.
Was bedeutet Echtzeit denn bei Power BI überhaupt?
Wenn ich die Pools (Workspaces) in der Cloud erstellt habe, darf ich diese nur in der Proversion max. 48 Mal am Tag, ansonsten nur 8x, aktualisieren. D.h., max 2x pro Stunde oder alle 3 Stunden. Was ist da Echzeit?

Aber was heißt schon Echtzeit. Wir wissen ja nun zu genüge, dass eine Abfrage, die eine gewissen Zeit dauert, bereits wenn sie fertig ist, nicht mehr aktuell ist. Da kann auch bei allen Versprechungen Microsoft nichts daran ändern.

Da nehme ich lieber unsere eigene Software. Die Anzahl der Aktualisierungen bestimmt man selber, ob nun inkrementell oder nicht.
Und DirectQuery können wir mit jeder Datenbank, egal ob mit eckigen Klammern oder Anführungszeichen.

[BenderD]

... nromalerweise greift man eh auf ein Viewlayer zu.
D*B

[Fuerchau]

Darum gings mir ja nicht, da nun Power BI mit Anführungszeichen im SQL nicht zurechtkommt.
Microsoft möchte eben "select [Menge] ..." statt "select "Menge" ...." generieren.
Ich habe nun da keine Lust, noch eine weitere View mit 10-stelligen Namen in Großbuchstaben zu erstellen, die ich dann wieder alle innerhalb von Power BI wieder als Überschriften überarbeiten muss.