mach das erstmal ohne Datenbank.
Eine Datenbank kannste später noch hinterlegen, und es ist zigfach einfacher, die Logik erstmal ohne DB auszuprogrammieren, als während der gesamten Entwicklungszeit (mindestens mehrere Monate) auch noch die DB immer mit-pflegen zu müssen.
Bzw überhaupt erstmal lernen, wie man eine Db aufbaut und addressiert.
Guck dir dieses Tut an: codeproject.com/Articles/10351…ped-Dataset-for-Beginners
Es sind drei aufeinander aufbauende Artikel.
Es gibt auch Filmle - das sind aber eher Schlaglichter denn ein stetiges Voranschreiten: vier Views-Videos

Tobias121 schrieb:

muss ich eine weitere Datenbank für Regiebericht anlegen, wenn diese gespeichert sein soll?

Ich weiss nicht, was ein RegieBericht ist, aber überschaubare Projekte sollte man unbedingt nur mit einer DB entwickeln.

Tobias121 schrieb:

Ist mein Konzept überhaupt so richtig durchdacht? Beziehungsweise geht es in die richtige Richtung?

Nein, überhaupt nicht.
Die ganze Denkweise ist an Listviews orientiert - das Denken selbst musste ganz neu lernen.
Für eine Datenverarbeitung muss man in Daten denken - nicht in Controls.
gugge die Tuts - wenn du damit was anfangen kannst, gibts Hoffnung

ErfinderDesRades schrieb:

gibts Hoffnung

Jo, ich tät schon bischen Hoffnung prognostizieren.
Deine Begriffe sind ganz falsch, aber offsichtlich denkst du schon ein bischen in "Entitäten".
Also du erwähnst schonmal, dass es Mitarbeiter gibt, Aufträge, Kostenvoranschläge, Kunden, Leistungen, Material, Stundensatz,...

Das sind die Dinge, auf die man fokussieren muss, wenn man ein relationales Datenmodell konzipiert.
Nur eben das sind keine ListviewItems, und auch keine Datenbanken, sondern es sind Entitäten, und die kann man repräsentieren durch Tabellen.
Traditionell geht man von Datenbank-Tabellen aus, aber dann muss man immer noch zusätzlich mit DataTables arbeiten.
Daher empfehle ich immer, zunächstmal die DB wegzulassen, mit den DataTables hat man schon genug zu tun (reichlich!).

Wiedemauchsei.
relationale Datenmodellierung versucht nun, diese Entitäten miteinander in Beziehung zu setzen.
Also im Grunde gehts immer um dieselbe Frage: Hat A viele B oder hat B viele A?

einfaches Beispiel: Hat ein Kunde viele Aufträge, oder hat ein Auftrag viele Kunden?
Natürlich hat ein Kunde viele Aufträge (beauftragt).
Und ein Auftrag verweist auf nur genau einen Kunden.

Solche Fragen sind zu klären - im Grunde ganz einfach, praktisch dann aber TeufelImDetail.
Letztendlich hängt alles mit allem zusammen, also ein Mitarbeiter hat (über mehrere Stationen) auch mit Material zu tun, ja sogar mit Kostenvoranschlägen.

Daher ist sehr empfohlen: Nur eine Datenbank, und nur ein Dataset.
Wo alles drin ist, sodass man die Dinge miteinaner in Beziehung setzen kann.

---

Übrigens gibt es auch eine Alternative zum Dataset: nämlich Klassen, die man sich mit EntityFramework generieren lassen kann.
Oder das EF generiert DB-Tabellen anhand von Klassen.
Dann hat man kein typisiertes Dataset mehr, wo alles drinne ist, sondern glaub "EntityContainer" heisst das (Raiders heisst jetzt 'Twix', und Facebook heisst jetzt 'Meta').
Ist neuer, und die Mehrzahl der Entwickler schwören darauf (warum auch immer).
Nur ich bleib bei meiner Bevorzugung des TypDatasets, weil das auch ohne Datenbank auskommt.
Und weil es ein integriertes Entity-Relation-Diagram mitbringt, wo man das relationale Modell in einer Übersicht konzipieren kann.
Und zum typDataset kann man Tutorials schreiben, die lauffähige Sample-Solutions mitliefern.
Das ist bei EF nicht möglich, weil da muss immer auch eine Datenbank aufgesetzt sein, und Datenbanken kann man schlecht verzippen.

Entweder Access oder .Net und Datenbankserver.
Wenn Du mit Access arbeiten willst, solltest Du die ganze Anwendung in Access entwickeln. D.h. alles Tabellen, Abfragen, Formulare und Berichte in Access (Und auf jeden fall mit der Trennung von Frontend (Logik und Oberfläche) und Backend (Daten).
Oder die Oberfläche und Logik in .Net und die Daten auf einen Datenbankserver (bitte nicht Access verwenden).

Wo Du in Deinem ersten Post von Datenbanken redest, solltest Du lieber von Tabellen reden. Diese Tabellen liegen dann alle in Deiner Datenbank diese sind über Beziehungen (Relationen) verknüpft. (Sowas wie der SVerweis in Excel aber viel mächtiger).

Kurzform: Access ist ein gutes Frontend für eine schnelle Lösungsentwicklung aber ein schlechtes Backend.

Längere Form:
Access ist dateibasiert. Da kann es zu es Schwierigkeiten mit dem Zugriff im Netzwerk kommen. Access ist nicht Cloud-/Sharepoint fähig. Access kennt keine datenseitigen Trigger. Access kann keine Transaktionen und auch keinen automatischen Rollback. Access kennt keine zeitabhängigen Event Trigger (z.B. in der Nacht einen Benachrichtigung zu versenden). usw.

Deshalb solltest Du wenn Du schon mit .Net arbeitest auch ein vernünftiges DMS (DatenbankManagementSystem) verwenden. Was Du da verwenden willst ist letzte endlich egal. Hier eine nicht vollständige und nicht gewertete Auswahl:
MS SQL Server
Oracle
mySQL/MariaDB
PostgreSQL
Selbst für die ersten beiden gibt es kostenfreie Versionen, die gewerblich genutzt werden können. Und auch die IT freut sich, weil sie das DMS vernünftig warten und sichern können.

wie gesagt - meine Empfehlung: Lass die DB erstmal weg.
Wenn die Anwendung fertig ist, kannst du immer noch eine hinterlegen, egal welche.

Als Alternative sehe ich die Idee von INOPIAE, deine Anwendung direkt im Access-Frontend zu entwickeln.
Da wirst du aber in einem Access-Forum bessere Unterstützung für finden.