Das ist ein sehr grosses Projekt für einen Programmier-Einsteiger.
Und lösen kannste das nur, indem du programmieren lernst.
Und Programmieren lernen tuste am besten von Anfang an. Also Was sind Datentypen, wie funktioniert VisualStudio, verschiedenste Schlüsselworte, wie lerne ich, vb.Net-Methoden zu benutzen, und vb6-Methoden nicht zu benutzen, Objektorientierung pipapo.

All das: Datenverarbeitungs-Vorraussetzungen

Das einzige, was du erstmal nicht brauchst, ist eine Datenbank - aber das ist in den weiter-verlinkungen des gegebenen Links auch begründet - ich mags nicht wiederholen.

Hatte deine Initiative im Dingens-Bereich kein Erfolg, wo du einen Anleiter suchtetest? Das scheint mir nämlich eine gute Idee.

Dein Datenmodell diskutiert man am besten anhand von hier eingestellten Screenshots des DatasetDesigners

(Den Dataset-Designer wirste auch kennenlernen, wennde dem Link folgst)

Visual Studio bedienen hat mal nichts mit Programmieren lernen zu tun.

Rein Datenbank verstehen, erstellen, abfragen, es gibt sogar reine Datenbankprogrammierer.

In dem Falle könntest du dann erst mal dein Excel als Frontend nehmen.

Und dann das Entity Framework mit Database First. Da kann man dann als Programmierer Objektorientiert Arbeiten

Mit einem Multiuse System bindest du dir mit dem Dataset einen Klotz ans Bein. Da ein vernünftiges Datensatz sperren hin zu bekommen....

jo, wie du wolle. Ungefähr das Gegenteil von allem, was ich gesagt hab

Nun kann @cmdrcook selbst entscheiden (oder ausprobieren), welcher unser beider Posts ihn weiter bringt.

Hallo cmdrcook

Deine Datenbank habe ich mir einmal angeschaut und verstehe dein Problem direkt. Du hast die Tabellen tblEinheitGruppen und tblEinheiten erzeugt. Wieso schreibst du tbl vor die Tabellen? Jede Tabelle sollte so heißen wie du es meinst. Ich nehme sogar noch kürzere Namen in dem ich alle Vokale aus dem Namen kille. Also aus Einheiten wird Enhtn und aus EinheitGruppen wird EnhtGrppn. Weil das kann man trotzdem lesen. Besser noch wäre es, wenn du die Tabellen in Englisch schreibst, dann ist das nochmal einfacher.

Dein 2. Problem ist, dass du nicht verstehst, wie ein relationales Datenbankmodell aufgebaut wird. Das sieht man daran, dass du zwar 2 mal eine Spalte ID vergeben hast, mit korrekten Primärschlüssel. Aber sonst scheint das nur ins Blaue geschossen zu sein. Du verwendest in jeder Spalte auch noch den Tabellennamen. Macht einfach keinen Sinn, da die Spalte meistens über Tabellenname.Spaltenname angesprochen wird.

Um das einmal abzuschließen. Die Tabellen sollten heißen wie sie heißen, ist aber Geschmackssache. Alles was keine Tabelle mehr ist, sollte dann eine Abkürzung haben. Also V_Name für Views etc. Nehme die Tabellennamen aus den Spalten heraus.

Du hast also Einheiten und EinheitGruppen. Beides hat eine ID und du möchtest für eine Einheit eine Gruppe festlegen. Dann musst du die Spalte Einheit_Gruppen in Einheiten löschen (Umbenennen) und durch EinheitGruppenID ersetzen. Der Name ergibt sich aus TabellenNameSpaltenName der Ursprungstabelle. Dann ziehst du die ID der EinheitGruppe auf die Spalte EinheitGruppenID. Die referentielle Integrität ist wichtig. Damit verhinderst du das jemand eine Gruppe aus EinheitGruppen löscht und dann in Einheiten kein gültiger Verweis mehr vorhanden ist. Wenn also jemand die ID = 1 in EinheitGruppen löscht und noch Werte in Einheiten vorhanden sind, wo in der Spalte EinheitGruppenID noch der Wert = 1 steht. Dann wird die Datenbank einen Fehler auslösen und ein Löschen der EinheitGruppe ist nicht möglich.

Die Werte Aktualisierungweitergabe und Löschweitergabe solltest du nicht aktivieren. Denn das bewirkt genau das. Die Aktualisierungsweitergabe ändert jede Eintrag in der Spalte EinheitGruppenID in Einheiten, wenn du die ID in der Tabelle EinheitGruppen veränderst. Das kann hilfreich sein, aber mir ist kein Fall bekannt, indem dies jemals notwendig war. Die Löschweitergabe löscht z.B. jeden Eintrag in Einheiten, wenn du eine EinheitGruppe löschst. Und das ist ein Supergau. Ich würde das Löschen eines Eintrags in EinheitGruppe nur zulassen, wenn auch alle Einträge in Einheiten nicht mehr auf diese Gruppe verweisen.

soweit. Das Thema relationale Datenbanken ist wirklich komplex. Ich empfehle dir einen Kurs zu machen, wenn du wirklich Interesse hast. Denn auch eine Access-Datenbank ist keine Datenbank. Das ist nur ein Spielzeug für EinzelAnwender. Ab ca. 10 Benutzer bricht die Performance der Datenbank komplett ein und es macht keinen Spass mehr damit zu arbeiten. Selbst habe ich Access nur zum Designen am Rechner verwendet, bin aber schnell auf Oracle oder SQLServer umgestiegen. Weil das muss man sich ehrlich gesagt nicht antun.

Und deine Idee ist gut, aber die Umsetzung wird richtig komplex. Und du wirst dabei sehr viele Fehler machen. Ansich auch ok. Aber nicht dann, wenn das auch produktiv eingesetzt werden soll. Ansonst kann ich dir die Hilfe von MS empfehlen. Nicht einfach durchscrollen, sondern lesen und verstehen.

support.office.com/de-de/artic…be-457b-b992-2f6fb812b58f

soweit...

@Sio_x

Grundsätzlich sollte kein Prefix vor die Tabelle und der Tabellenname nicht als Prefix vor eine Spalte, aber das ist nun mal die gängige Notation in Access Tutorials. Also Augen auf beim mosern.
Aber die Tabellennamen noch zu verunstaltet ist echt nicht OK

Ich bin selbst kein großer Access Fan, aber diese Überheblichkeit muss nicht sein. Accessnals Backend mit einer guten Server Software davor geht viel.
MS SQL Express geht natürlich viel mehr

Ja, deinen Einwand kann ich verstehen und wie du mich als abgehoben bezeichnest, ebenfalls. Aber ich sehe immer daran, dass die Leute aus der Access-Welt kommen. Und dann sehe ich auch die undurchdachten Konstrukte. Leider sind meistens die Umsetzungen einfach ...

Entschuldigung, jeder fängt klein an. Aber bei einem solchen Projekt muss der Entwickler auch eine gute Lernkurve vorweisen. Ansonst scheitert dies auf ganzer Linie.

Es gibt mehrere Wege. Für die Programmierung:

1. Du versuchst deinen VBA Code in Visual Basic Code umzuschreiben. Da wirst du schon einen steinigen Weg haben. Das meine ich nicht negativ, sondern du musst umdenken. VBA und Visual Basic unterscheiden sich. Aus Gründen der Kompatibilität schleppt auch Visual Basic noch einige VBA Komponenten mit sich herum. Wie MsgBox, statt MessageBox. Dabei solltest du aber evtl. auf diese alten Sachen verzichten.
   
2. Du verwirfst den gesamten VBA Code und machst es diesmal von vorn.
   

Für die Datenbank:

1. Du schreibst selbst deine Klassen zur Datenbank-Verbindung. Was aber als Anfänger nicht umbedingt zu empfehlen ist.
   
2. Du überlässt Visual Studio die Datenbankverbindung. Du kannst darin auch die Datenbank bearbeiten, Abfragen erstellen etc. Für einen Anfänger wohl die beste Lösung.
   
3. Du verwendest das Entity-Framework für die Datenbank. Dabei wird deine Datenbank objektorientiert abgebildet. Das Abfragen der Daten kann aber einen Anfänger leicht überfordern. Wobei das Anlegen der Daten, dabei relativ einfach scheint.
   

Du wirst dich mit Klassen, Variablen, Datentypen, Sichtbarkeiten (also wie verdeckt sollten Variablen sein), Zugriffsmodifizierer etc. beschäftigen müssen. Das hat allein bei meiner Ausbildung 6 Monate Zeit in Anspruch genommen. Und du solltest das nicht unterschätzen. Vor allem, da du ja wahrscheinlich eh versuchen wirst den prozeduralen Ansatz aus VBA (Excel) in die Objektorientiere Umgebung (VS2017, VB oder C#) zu transferieren.

Das wird viel Arbeit. Und wenn du nicht in falsche Denkmuster verfallen möchstest, dann empfehle ich dir echt Hilfe dazu zu holen. Und zwar im ersten Step durch Bücher wie: Einstieg in Visual Basic 2017 oder Einstieg in C# in Visual Studio 2017. Oder aber ähnliche Literatur. Das hat nämlich den Vorteil, dass du es richtig lernst. Den Code, den du für Probleme, gerade in Richtung Visual Basic per Google findest, ist entweder schon älter und nicht mehr state of the art (z.B. inkludieren der Windows-Api für simple Dinge als unmanaged Code oder viel VB6), oder er ist bei den Datentypen, Sichtbarkeiten (also wie verdeckt sollten Variablen sein), Zugriffsmodifizierer etc. noch recht ausbaufähig.

Genauso solltest du dir Gedanken machen: Muss es unbedingt Visual Basic sein, vielleicht ist C# eine bessere Alternative? Gerade weil du in C# alte Denkmuster aus der VBA Zeit ablegen musst. Beide Sprachen habe ihre Vorteile, beide haben ihre Nachteile, am Ende münden beide in .Net Code.

Wie auch immer du dich entscheidest, es wird deine nächsten Schritte enorm beeinflussen. Wähle daher sorgfältig.

cmdrcook schrieb:

Auch wenn Ihr Profis wohl alle mit den Augen rollen werdet: ganz bei Null anfangen kann und will ich nicht. Ich brauche ein funktionierendes Beispiel, anhand dessen ich mir die Grundlagen aneignen kann.

Ich empfehle dir sehr dringend, doch mal in den von mir gegebenen Link reinzuschauen.
Andere mögen ja mit Fleiss jeden meiner Punkte demontieren, und dann selbst nichts konkretes anbieten.
Aber wenn du was konkretes möchtest, und sinnvoll aufgebaute Anleitung, und einen Weg von Null bis fertig, und lauffähige Codebeispiele - wie gesagt: Lass dich mir nicht vermiesen und vernebeln.

Übrigens ist "bei Null anfangen" zweideutig. Wenn du damit meinst, du musst alles ohne jede Vorlage aufbauen, dann hast du recht - solch wäre ineffizient und ist nicht nötig. Und ich habe dir jetzt 2 mal gesagt, wo du Vorlagen findest.
Wenn du mit "nicht ganz bei Null anfangen" allerdings meinst, du wüsstest schon ein bischen über Programmierung bescheid, dann irrst du dich (und wirst dich noch sehr wundern). Die VBA-Programmiersprachen sind von .Net unterschiedlicher als man es sich überhaupt vorstellen kann.
Leider funktionieren viele veraltete Vorgehensweisen nachwievor, ein Stück weit - quasi parallel zum "wirklichen" .Net. Und das ist das verheerende, weil wenn du die olle Grütze reproduzierst, kommt da nichts als Grütze bei raus. Da es aber kompiliert, und bischen geht, wurstelt man immer weiter in die falsche Richtung, und lernt nie - wie es richtig geht, und wie einfach das ist.