Laden...

Auftragsdaten für Kapazitätsplanung: WPF oder SourceGrid oder Excel-AddIn?

Erstellt von SideKick vor 11 Jahren Letzter Beitrag vor 11 Jahren 4.498 Views
SideKick Themenstarter:in
33 Beiträge seit 2011
vor 11 Jahren
Auftragsdaten für Kapazitätsplanung: WPF oder SourceGrid oder Excel-AddIn?

Hallo,

ich möchte Auftragsdaten aus einer Kapazität Planung in eine Datenbank (Oracle) speichern.

Derzeit werden die Daten in einem Excel-Sheet eingegeben und mit VBA verarbeitet

Mein Kollege aus der Fachdomäne möchte auf jeden Fall die oder ähnliche Ansicht und Handhabung wie im Excel. Jeder Projektleiter soll zukünftig nur seine Mitarbeiter sehen und verwalten können.

Nun habe ich schon ein bisschen im Internet geschaut.

Version A
Da habe ich einmal http://sourcegrid.codeplex.com gefunden.
• Ich denke das wird mit Sicherheit nicht mehr weiterentwickelt
• Wenn noch weiter Anforderungen kommen …. Kann ich damit noch leben?
• Ich weiß auch noch nicht ob ich die Daten von dem Planer in die Datenbank bekomme … hab es mir ja auch noch nicht angeschaut.

Version B
Einer sagte in einem Forum das man das mit XAML (.NET) machen könnte.
• Mit C#.NET arbeite ich schon.
• XAML wollte ich sowieso mal lernen, weiß aber nicht mit welchem Aufwand ich mein Projekt verwirklichen kann
• Ob ich diese Excel – Ähnliche Struktur nachbilden kann ?
• Ob dieses DataGrid mit der Datenbank interagieren kann ?

Nun meine Frage: Für welchen Weg würden Sie /Du sich entscheiden? Oder gibt es sogar noch einen besseren Weg ?
Vielen Dank

Anhang:
Welche Methoden benötige ich:
• Sieben Zellen zu einer Zelle Verbinden
• Mit einem Multi-Select mehrere Zellen markieren und Projektnummern per Button zuteilen
• Daten sollen in einer Datenbank gespeichert werden (Oracle)
• Erstellen der Tabelle während der Laufzeit (Anzahl der Spalten ist vom Projektleiter und deren Mitarbeiter abhängig)
• Export nach Excel
• Und andere Dinge bei denen ich noch kein Problem sehe

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo SideKick,

das Sourcegrid kenne ich nicht und wenn es keinen Branch gibt, der weiterentwickelt wird, oder etwas vergleichbares so ist Variante A wohl auszuschließen.

Mit WPF bekommst du das sicherlich hin, aber was spricht gegeben ein Excel-Addin?

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

E
180 Beiträge seit 2010
vor 11 Jahren

Nur weil etwas nicht weiterentwickelt wird, heisst es nicht das es automatisch nix taugt oder Wert ist, mal davon abgesehen das du ja den SourceCode mitgeliefert kriegst und auch selbst Hand anlegen kannst. Sourcegrid hat etliche Releases hinter sich und das über eine recht lange Zeit. Das letzte stable Release ist von Mitte 2010 und somit noch völlig ok. Inhaltlich deckt SG alles ab was du machen willst und bietet dir eine gute Doku mit vielen Fallbeispielen zum experementieren.

Ich würde dir zu Variante A) raten, weil sich in eine neue Sprache hineinzuarbeiten bei einem neuen Projekt ist immer ein unkalkulierbares Risiko, da du Neuland betrittst und auf keine Erfahrung derjeweiligen zurückgreifen kannst. Damit steigt automatisch der Fehlerfaktor und erhöht nachträglich Wartungsarbeiten.

Aber letzendlich deine Entscheidung.

SideKick Themenstarter:in
33 Beiträge seit 2011
vor 11 Jahren

Hallo,

vielen Dank für die Antworten. Ich finde beide Beiträge sehr Interessant.

Hallo @gfoidl

Mit WPF bekommst du das sicherlich hin,

Ok, ohne zu wissen wie ich weitermachen werde, möchte ich WPF zukünftig Lernen und anwenden. Tabellen zur Laufzeit zu generieren wird ja wohl kein Problem sein.

Mit WPF kann man wohl Dinge mache die man mit Windows Forms nicht machen kann, sehr Interessant.

was spricht gegeben ein Excel-Addin?

Excel-Addin habe ich schon … 4500 Codezeilen die Auswertungen und Diagramme erstellen.

Mehr weiter unten mit der Überschrift „Was habe ich“
**
Mein Gedanke wahr, …**

  • Ich mache ein C#.NET-Programm.
  • In diesem Programm werden Daten, für die Datenbank eingegeben (WPF-DataGridView oder SourceGrid)
  • Auswertungen werden innerhalb des Programms dargestellt.
  • Mit Diagrammen habe ich mich innerhalb C#.NET noch nicht beschäftigt. Crystal Reports oder Export ins Excel gibt’s ja auch noch … ist aber noch nicht mein Thema.
  • Da unsere z.B. Projektleiter, Kollegen und Controller gerne ihre Daten in einem Excel-Sheet haben, benötige ich auch immer ein Excel-Sheet die ich, wenn nötig, per Button automatisch erzeugen lasse.

Das Erzeugen von Excel-Sheets (mit Daten, Formatierung und Diagramme) per C#.NET zu erzeugt ist aufwendig.
Wenn der Benutzer ein Excel-Sheet manuell füllt, muss ich dafür keinen Code schreiben, hier gibt der Benutzer die Daten ein, die Formatierung erledigt die „Bedingte Formatierung“ die Auswertungen und Diagramme können relativ einfach per VBA-Code erzeugt werden.

Trotzdem hat die Methode auch viele Nachteile.

Mehr weiter unten mit der Überschrift „Was habe ich“

Hallo @Equilibrium

Nur weil etwas nicht weiterentwickelt wird, heißt es nicht das es automatisch nix taugt

Mit deinem Beitrag ist das SorceGrid bei mir wieder ganz nach oben gerutscht. Ich werde mir die Klassen bzw. den Code auf jeden Fall unabhängig von meiner Entscheidung anschauen. Überzeugt hat mich auch die Tatsache dass der SourceCode mitgeliefert wird.
Mit Sicherheit kann man mit der Lösung Tabellen zu Laufzeit erstellen?

Was habe ich?* Derzeit werden die Projektdaten vom Projektleiter eingetragen

  • Es kann immer nur ein Projektleiter (im Hauptsitz ca. 10 Personen) Daten eingeben. Wenn einer das Excel-Blatt offen hat muss der andere warten.
  • Das erste Sheet dient als Datenbank? Das in der ursprünglichen Form keine Programmierung beinhaltet hatte.
  • Eines Tages kam mein Chef und wollte eine kleine Auswertung. Dies verwirklichte ich mit einem kleine VBA-Add-In (400 Zeilen Code)
  • Projektleiter, Controller, Vorgesetzte und Andere gefiel das. Sie wollten immer wieder neue Funktionen / Methoden. (Auswertungen und Komplexe Diagramme)
  • Inzwischen hat das VBA-Add-In 4500 Code-Zeilen ohne Kommentare.
  • Fehlzeiten (Urlaub, Krank usw.), Personaldaten und Projektdaten kommen per ODBC / VBA aus unseren BDE-Datenbank und werden per Button in die Excel-Sheets geschrieben.
  • Benutzer ändern öfters diese Daten oder fügen neue Datensätze im Excel hinzu, obwohl diese in der Datenbank mit Hilfe eines Programms geändert werden sollten. Da die Struktur, das Format oder die Ranges nicht eingehalten werden kommt es hierbei öfters zu Technischen Problemen. Natürlich kann man für jedes Problem auch mit VBA meistens eine Lösung schaffen. Mit einer Datenbank als Speicher, die mit einer Restriktiven Eingabe für eine bessere Datenqualität sorgt sind Programmierungen zwecks Validierung und Falscheingabe oft nicht notwendig.
  • Zudem kommt dazu dass man das Ding wieder umbauen sollte weil sich die Anforderungen geändert haben … uff.
  • Ich würde gern einen besseren Weg gehen … Datenbank und (nicht zwingend) eine mächtigere , flexiblere Programmiersprache
  • Den besten Weg ohne zu viel Aufwand zu wählen ist für mich wichtig
  • Mit dem Verwirklichen von Diagrammen außerhalb von Excel habe ich mich nur am Rande beschäftigt
  • Excel-Export (Etwas umständlich) aus Forms (C#.NET) habe ich in der Vergangenheit schon gebaut.

Warum eine Datenbank?

Daten wurden in der Vergangenheit in dem Excel-Sheet falsch eingegeben
• -- Formatfehler vom Anwender
• -- Der Anwender verändert immer wieder die Ranges die jedoch für meinen Code immer gleich sein sollten.
• -- Eintragen von Projetnummern die es nicht gibt
• -- Personaldaten die nicht in der Datenbank vorhanden sind, werden falsch eingegeben
• -- Eintragen von Text (Auto XY anstatt Auftragsnummer) die nicht vom Programm ausgewertet werden können.
Niederlassungen sollen auch Ihre Projektplanung abgeben
• -- Entweder per VPN direkt in die DB
• -- Oder per Export File das an den Hauptsitz übermittelt wird
Handling
• -- Bei einer Datenbank kann man wesentlich einfacher Abfragen (SQL) machen ohne erst die Ranges per Code zu ermitteln.
• -- Zudem fällt in den meisten Fällen die Validierung per Programmiercode weg da die Datenqualität wesentlich besser ist. Der Benutzer darf nur Valide Daten eingeben.
• Durch die schlechte Datenqualität (im Excel) kann es durchaus zu Falschauswertungen kommen 😦
• In einem anderen System (Nicht Excel) kann man relativ leicht eine Restriktive Eingabe erzwingen (z.B. Personalnummer und Aufträge aus einer Liste wählen)

Naja, jetzt habe ich drei Möglichkeiten?
• SourceCode
• Excel-Add-Ins (Hierbei müßte ich zusätzliche Validierungesfunktonen bauen)
• WPF

Schönen Gruß

S
93 Beiträge seit 2008
vor 11 Jahren

Also ich würde auch versuchen von "Excel als Datenbank" wegzukommen.
Bei der von Dir beschriebenen Größenordnung ist das, was Du vor hast meiner Meinung nach das sinnvollste Vorgehen.

Excel nur noch verwenden, um Daten zur Weiterverwarbeitung auszugeben.
Die komplette Ansteuerung von Excelk kannst Du mit NetOffice vornehmen.
Das ist dann gar nicht so aufwändig.

NetOffice - Ein versionsunabhängiger Wrapper für MS-Office

Und für Diagrammausgabe (wenn es dann doch mal Dein Ding wird), schau dir mal ZedGraph an. Da trittst Du das Chartcontrol von Excel sofort in die Tonne.

A flexible charting library for .NET

SideKick Themenstarter:in
33 Beiträge seit 2011
vor 11 Jahren

Hallo,

Vielen Dank an @san-software.

Ich werden mir ZedGraph und NetOffice auf jeden Fall anschauen.

Nun habe ich erst mal eine Menge Arbeit SorceGrid, WPF und später ZedGraph , und NetOffice anschauen. Ich freue mich schon darauf.

Ich würde mich freuen wenn noch jemand eine Idee oder Bemerkungen zum Thema WPF und SorceGrid hat.

Schöne Grüß
Karl

D
500 Beiträge seit 2007
vor 11 Jahren

Hi!

Warum bzgl. der Charts in die Ferne schweifen, wenn es doch so nahe liegt:

System.Windows.Forms.DataVisualization.Charting Namespace ()

Das Charting ist sehr gut, kommt urspruenglich auch von einer Firma, die sich auf Charts spezialisiert hat. ZedGraph ist nicht schlecht, passt sich aber optisch (meines Erachtens) nicht so gut in die WinForms ein und die API, welche man auch gut verwenden kann, merkt man an, dass diese einen Hauch von C++ hat.

Gruss,
DaMoe

Hinweis von gfoidl vor 11 Jahren

Siehe hierzu auch Samples Environment for Microsoft Chart Controls

SideKick Themenstarter:in
33 Beiträge seit 2011
vor 11 Jahren

Hallo,

Danke @DaMoe80

für die Diagramme habe ich nun die Möglichkeit System.Windows.Forms.DataVisualization.Charting Namespace () und ZedGraph.

Im Excel habe ich ein „gruppiertes und gestapeltes Säulendiagramm „ verwirklicht.

Kann ich mit einen der beiden Systeme auch ein „gruppiertes und gestapeltes Säulendiagramm“ verwirklichen?

Auf die Schnelle konnte ich keine Übereinstimmung im Internet finden.

Ich arbeite derzeit gerade an der Verwirklichung mit SourceGrid. Ich denke dass ich mein Ziel, das ja Zeitlich begrenzt ist mit SourceGrid erreichen könnte, obwohl ich schon der Meinung bin, das langfristig der Weg mit WPF der besser wäre. Ich werden mir WPF auf jeden Fall aneignen.

Vielen Dank bis hierher an @Alle

Karl