[Geloest] Navision Reports im Vergleich mit Reporting Serv

Hallo,

wir haben schon einige neue Reports auf Reporting Services entwickelt. Was ist den das pro und contra eurer Meinung nach?

Unsere IT-Mitarbeiter haben kein grosses Interesse C/AL zu lernen und somit haben wir nur einen Freiberufler, der uns bei Navision Reports Software Loesungen behilflich ist. Gibt es Grenzen bei der Programmierung von Reports mit Reporting Services im Vergleich zu C/AL?

Ausserdem kann ich mir schwer vorstellen, dass man die existierenden Reports so einfach umwandeln kann, wie das fuer Nav2009 angekuendigt wird. Habt ihr da irgendwelche Erfahrungswerte?

Cheers,
Stef

Zuletzt geändert von kaetchen am 12. Januar 2009 23:32, insgesamt 2-mal geändert.

Moin,

zu diesem Thema gibt es noch einige Irrtümer und Missverständnisse ....

Gibt es Grenzen bei der Programmierung von Reports mit Reporting Services im Vergleich zu C/AL?

Oh ja!

• Sämtliche FlowFields müssen über SQL-Statements nachgebildet werden (= mehr Aufwand). Wird die CalcFormula in NAV geändert, muss der SQL Report ebenfalls geändert werden.
• Berichte über Reporting Services sind schwieriger zu debuggen (als Oberbegriff für die Fehlersuche und deren Behebung).
• Es gibt keine Trans-Sections (also TransHeader, TransFooter).
• Das von NAV gewohnte Layout (wenn denn gewünscht) ist deutlich komplizierter umzusetzen (zeitlich deutliche mehr Aufwand)
• Das Sicherheitsmodell aus NAV greift in SQL Reports nicht und muss anderweitig abgebildet werden.
• Die Reports sind per se nicht multilanguage-fähig. Alles muss manuell nachgestellt werden.

Das waren nur die, die mir spontan eingefallen sind, und das war mit Sicherheit nicht der Wahrheit letzter Schluss ...

Ausserdem kann ich mir schwer vorstellen, dass man die existierenden Reports so einfach umwandeln kann, wie das fuer Nav2009 angekuendigt wird.

SQL Reports sind nicht gleich NAV2009-Reports im RTC!

SQL Reports (mal ganz ohne NAV betrachtet):

• Du erstellst eine oder mehrere SQL-Statements (sog. DataSources) und bist völlig frei in der Verknüpfung von Daten selbst unterschiedlicher Datenbanken.
• Es wird (mehr oder minder, möge Jörg Stryk mich hier korrigieren ) nur das an SQL-Statements an den SQL-Server gefeuert, was du selbst geschrieben hast. Die Performance ist dadurch super.
• Die Reports liegen auf einem Report Server und werden über den Browser aufgerufen. Sie hängen nicht an NAV und lassen sich völlig unabhängig von NAV aufrufen und verwalten.
• Die Reports lassen sich per se sofort in Office-Dokumente oder PDFs umwandeln.

SQL Reports in NAV 2009

• Die Report-Definition hängt an einem NAV-Report. Es gibt keine zentrale Stelle (wie den Report Server), um diese Reports allen öffentlich zugänglich zu machen. Damit fehlt auch die Möglichkeit zu Abonierung.
• Ich habe die Stelle mit dem Export nach Excel & Co. noch nicht gesehen ....
• Die Daten liefert dir NAV in einer einzigen (!) tempr. DataSource-Tabelle vor. Das heißt außerdem, dass die Performance an NAV hängt. Du kannst nichts editieren; nur das Layout kannst du erstellen.
• Diese Reports sind Multilanguage-fähig. Das liegt daran, dass sämtliche Controls (mit einer bestimmten Eigenschaft) im NAV-Reports in die DataSource des SQL-Reports geschrieben werden. Da das aber dutzende (und noch viel mehr!) von Feldern ergibt, wird das nicht gerade übersichtlich.
• Die automatische Erstellung des SQL Reports funktioniert nur bedingt. Wenn dein NAV-Report nur aus "echten" DataItems besteht (also Tabelle wie Item, Sales Line etc.,), dann kann das Layout richtig übertragen werden und du hast nur wenig bis gar nichts nachzubearbeiten.
  Alles, was nicht automatisch konvertiert werden kann (z.B. Integer-DataItems), wird im Layout einfach weggelassen und du darfst das mühsam per Hand nacharbeiten.

Dies war noch nicht alles, aber ich hab nicht so viel Zeit

Sämtliche FlowFields müssen über SQL-Statements nachgebildet werden (= mehr Aufwand). Wird die CalcFormula in NAV geändert, muss der SQL Report ebenfalls geändert werden.

Diese Erfahrung haben wir schon bei der Umstellung auf SQL Server gemacht. Ich hatte eigentlich gehofft MS haette dafuer eine Umwandlungsroutine geschrieben in NAV2009.
Ich habe keine wirkliche Erfahrung mit C/AL...was ist das "Sicherheitsmodell". Vielleicht is das nur ein Sprachenhandikap, da wir die englische Version haben.

Es wird (mehr oder minder, möge Jörg Stryk mich hier korrigieren ) nur das an SQL-Statements an den SQL-Server gefeuert, was du selbst geschrieben hast.

Wie werden die Reporte gepublished? Muss man das Ganze immer noch in MS Visual Studio designen oder hat Navision eine eigene Layout Loesung?

Irgendwie kann ich mir den technischen Ablauf nicht richtig vorstellen. Im Moment schreiben wir unsere "Stored Procedure" in SQL und der layout wird in Visual Studio gemacht, dann wird der Report deployed (im Deutschen "entfaltet"), aber ich wuerde es eher "compilieren" nennen.

Die interessante Frage ist nun....welche Vorteile hat die Umstellung auf NAV2009 im Hinblick auf die Benutzung von Reporting Services, oder ist das Ganze nur wieder "Glossy Paper" Material?

Cheers,
Stefanie

Diese Erfahrung haben wir schon bei der Umstellung auf SQL Server gemacht. Ich hatte eigentlich gehofft MS haette dafuer eine Umwandlungsroutine geschrieben in NAV2009.

In den NAV2009-Berichten werden dir die FlowFieldinhalte bereits fertig bereit gestellt.

Wie werden die Reporte gepublished?

In NAV2009: Wie gesagt gar nicht. Der VS-Bereicht hängt am NAV-Bericht.

Muss man das Ganze immer noch in MS Visual Studio designen

Ja.

Irgendwie kann ich mir den technischen Ablauf nicht richtig vorstellen.

Nochmal:
Du bist in NAV, designst einen "normalen NAV-Report", drückst einen bestimmten Menüpunkt und es öffnet sich Visual Studio (zur Bearbeitung eines VS-Berichts). Dort ist bereits eine einzige DataSource bereit gestellt (die du nicht manipulieren kannst). Du passt das Design noch an, schließt VS wieder. Dann bist du wieder in NAV und wirst gefragt, ob deine Änderungen übernommen werden sollen.

Die interessante Frage ist nun....welche Vorteile hat die Umstellung auf NAV2009 im Hinblick auf die Benutzung von Reporting Services, oder ist das Ganze nur wieder "Glossy Paper" Material?

Es wird Reporting Services genutzt, ohne dass du dir Gedanken um SQL-Statements (und die Bereitstellung durch einen Report-Server) machen musst. Dies ist vor allem bei komplizierten Reports mit zig DataItems und temp. Tabellen von Vorteil. Die Pfege als Solche erfolgt von NAV aus.

Im übrigen sind alle Angaben ohne Gewähr
Bin leider kein Reporting-Services-Experte, sondern mehr oder minder einfacher Anwender, der die Reports sowohl in Reporting Services als auch in NAV 2009 erstellt hat.

Du bist in NAV, designst einen "normalen NAV-Report", drückst einen bestimmten Menüpunkt und es öffnet sich Visual Studio (zur Bearbeitung eines VS-Berichts). Dort ist bereits eine einzige DataSource bereit gestellt (die du nicht manipulieren kannst). Du passt das Design noch an, schließt VS wieder. Dann bist du wieder in NAV und wirst gefragt, ob deine Änderungen übernommen werden sollen.

Meinst Du "Data Source" oder "Dataset". Entschuldige, aber ich habe immer noch Probleme mir das Ganze richtig vorzustellen.
Die "Data Source" in VS ist doch nur der Verweis auf die Navision Datenbank in der die Objekte gespeichert sind, die normalerweise sowieso nur einmal erstellt wird ausser man will seine Datenbank auf einem anderen Server hinterlegen.
Das "Data Set" dagegen ist das Resultat des SQL Queries, sprich die Datenfelder und ihre Inhalte, gemaess der Queryabfrage. Ich koennte mir vorstellen, dass dies die Information ist, die man nicht manipulieren kann, da diese Abfrage in Navision programmiert wird und nicht als "Stored Procedure" in einem SQL Query.

Um ganz ehrlich zu sein, ich sehe den Vorteil der Integration von VS in Navision nicht, zumal Du erwaehntest, dass man da wahrscheinlich nochmal nacharbeiten muss, da das compilen nicht 1 x 1 ist.

Der Vorteil von Reporting Services fuer mich ist, dass man recht einfach ein SQL Query erstellen kann und das Selektieren der Dateifelder, sowie die Verknuepfung von Dateien recht einfach ist. Wie Du erwaehnt hast kann man sogar Dateien von anderen Applikationen verknuepfen.
Ausserdem haben wir zwei unabhaenige Datenbanken, eine in Fiji und eine in NZ. Wir koennen also das Reportwesen vereinfachen, ohne in Navision eine Firmenkonsolidierung vorzunehmen.

Aber im Prinzip glaube ich, dass meine Frage beantwortet ist. Ich hatte gehofft, dass Navision eine Art Tool fuer die SQL Queries bereitstellen wuerde und es damit einfacher waere die Felder und Dateiverknuepfungen von Navision aus zu manipulieren und auch eine Art Wizard dafuer zu haben. Der Report Builder ist ja doch ziemlich 'beschraenkt'.

Ich wuenschte, dass ich mehr Erfahrung mit C/AL haette, aber niemand in unserem IT Team ist wirklich interessiert es zu lernen. Training wird sowiso nicht genehmigt und es gibt mehr Material fuer SQL Training als fuer Navision C/AL. Vielleicht ist es ja gar nicht so verwirrened wie es aussieht

Vielen Dank fuer Deine Erklaerungen.

Cheers,
Stefanie

Meinst Du "Data Source" oder "Dataset". Entschuldige, aber ich habe immer noch Probleme mir das Ganze richtig vorzustellen.

Kein Wunder, wenn ich etwas anderes schreibe, als ich meine
DataSet ist richtig.

Ich koennte mir vorstellen, dass dies die Information ist, die man nicht manipulieren kann, da diese Abfrage in Navision programmiert wird und nicht als "Stored Procedure" in einem SQL Query.

Gute Vorstellungskraft

Um ganz ehrlich zu sein, ich sehe den Vorteil der Integration von VS in Navision nicht

DIE Antwort kann und soll dir auch nur MS geben
Was ich hier zum Besten gegeben habe, sind einfach meine persönlichen Eindrücke ... Experten dürften sich die Haare raufen, aber besser als gar keine Antwort ...

Ich hatte gehofft, dass Navision eine Art Tool fuer die SQL Queries bereitstellen wuerde und es damit einfacher waere die Felder und Dateiverknuepfungen von Navision aus zu manipulieren und auch eine Art Wizard dafuer zu haben.

Ja, davon träume ich auch

Ich wuenschte, dass ich mehr Erfahrung mit C/AL haette, aber niemand in unserem IT Team ist wirklich interessiert es zu lernen. Training wird sowiso nicht genehmigt und es gibt mehr Material fuer SQL Training als fuer Navision C/AL. Vielleicht ist es ja gar nicht so verwirrened wie es aussieht

Ich bin ganz froh, von Anfang an erfahrende Programmierer an meiner Seite gehabt zu haben; manches ist einfach erklärungsbedürftig. Aber mit dem Forum hast du schon einen guten Start erwischt.
Insofern - viel Erfolg!