Servus,

da eine Access DB immer nur von einem User genutzt werden kann musst du entweder einen Serverdienst schreiben der mit der Access DB kommuniziert und die Daten für die Clients zur Verfügung stellt, oder du nutzt einen MS SQL Server (Express) denn hier können mehrere User gleichzeitig zugreifen. Auch beim MS SQL wäre es möglich einen Serverdienst zu nutzen.

Auch das wäre möglich.
[Klugscheißermodus]Wobei der Apache jetzt nur indirekt mit dem MySQL Server zu tun hat. Den benötigst du höchstens für phpMyAdmin[/Klugscheißermodus]

Ich empfehle Gespeicherte Prozeduren und Views einzustezen

Hi,

also für mich sieht das nach folgenden Tabellen aus:
S_Adresse
S_Interessent
S_Kunde
S_Ansprechpartner
S_Bemerkung
S_Vertreter
S_Aktionen
V_Aktion
V_InterVertreter

Aufbau wäre für mich:
Es werden Vertriebsaktionen (S_Aktionen) angelegt, wie zB. Neukundengewinnung oder auch für die Einführung von neuen Projekten. Dieser Grundstamm würde in S_Aktionen festgelegt (und ggf. immer erweitert).
Es gibt mehrere Vertreter (S_Vertreter) die sich um die Kunden kümmern.
Zudem gibt es eine Tabelle für Interessenten (S_Interessent). Jeder Interessent könnte einen oder mehrere Vertreter/Betreuer zugewiesen bekommen (V_InterVertreter). Eine n-Tabelle ist nötig, da ein Interessent mehrere Betreuer und ein Betreuer mehrere Interessenten haben kann.
Wenn ein Interessent zu einem Kunden wird, werden die rein Kundenspezifischen Daten wie zB. Konditionen, Bankdaten usw, die ein Interessent nicht benötigt im Kundenstamm hinterlegt und verknüpft (S_Kunde). Hierfür muss im Interessentenstamm das Feld "Kundennummer" vorhanden sein.

Jedes dieser Projekte hat verschiedene Einzelaktionen (Anruf, Brief, Email Korrespondenz - hier könnten die detaillierten Daten angegeben werden) (V_Aktion).

Die Ansprechpartner können in einem eigenen Stamm hinterlegt werden (S_Ansprechpartner). Jedem Ansprechpartner wird dann die zugehörige Interessentennummer hinterlegt.

Für Interessent, Vertreter und Ansprechpartner gibt es einen gebündelten Adressstamm in dem alle Adressdaten hinterlegt werden können (S_Adresse). Jeder Interessent, Vertreter und Ansprechpartner erhält nur eine Adressnummer.

Gleiches gilt für Notizen/Bemerkungen.

Jeder Interessent, Vertreter, Ansprechpartner und jede Aktion kann Bemerkungen hinterlegt bekommen.(S_Bemerkung). Jede Bemerkung bekommt ein Schlüsselfeld mit der Info zu wem die Bemerkung gehört.

Das alles könnte Problemlos über eine Access oder SQLite DB oder jede Art von Datenbank abgebildet werden.
Hierfür könntest du die Tabellen in einer Access-DB anlegen und die Exe des VIS-Moduls ins Netzwerk legen, sodass du diese bei Änderungen am Programm einfach austauschen kannst.

Oo Hoffe das war passend zur Frage XD

@MemoAnMichSelbst

imho kann man eine Access DB nur einmal zur Zeit zum Schreiben öffnen. Was dann bedeuten würde das zwei MA nicht arbeiten können.

Du kannst dir sicher sein das die MA ihr Programm nicht zwischendurch schließen wollen

BTW: Warum die S und V Präfixe in den Tabellen Namen?

Deshalb schrieb ich ja von einem VIS Modul (welches die DB nur öffnet und anspricht wenn es Daten braucht). Wir sind hier ja im VB und net Access-Forum.

Access sollte bei einem Mehrbenutzerbetrieb nur als Backend dienen. Und eine Exe kann so oft wie gewünscht aufgerufen werden. Gleiches wird hier schon lange an vielen kleinen Stellen gemacht.
Zudem muss nicht immer schreibend aufgerufen werden. Solange das VIS-Modul nichts zu schreiben hat, ist nen Readonly-Aufruf völlig ausreichend.

EDIT:
S = Stamm
V = Vertrieb
E = Einkauf
F = Fibu usw.
Rein der Übersichtlichkeit halber. Gerade so nen kleines VIS-Modul wird schnell zu nem CRM Modul und immer größer. Wenn man da bei der Benamung nicht aufpasst hat man schnell ein riesen Heckmeck.
Durch die Präfixe kann man bestimmte Tabellen die ähnlich aber anders sind schnell und gleich benamen und erkennen.
V_BelegKopf
V_BelegPos
E_BelegKopf
E_BelegPos
als Beispiel

EDIT2:
@ TE ist mit Sonneborn das Möbelhaus gemeint oO

EDIT3:
Man öffnet und speichert keine Datenbank. Man greift auf sie zu.
Hier gibt es verschiedene Arten... Hier wird vom @ErfinderDesRades immer vorgelebt:
Alle Daten beim Aufruf laden (Dataset - lokales Abbild der Daten) und bei Änderungen die Änderungen zurück in die Datenbank übertragen. Schreibrechte auf die DB braucht man in dem Fall NUR bei der Übertragung von Änderungen.
Halte ich ab einer gewissten Datenbankgröße für kaum gangbar. Aber bei deiner aktuellen Aufgabenstellung ist das wohl der beste und einfachste Weg. Hierfür sind nur minimale Programmierarbeiten nötig. Das geht fast alles im grafischen Designer.

fsonneborn schrieb:

Meinen bisherigen Kenntnisstand im Bezug auf vb.net würde ich als gering einschätzen.

Das ist sehr schlecht, weil dieses Projekt ausgezeichnete vb.net-Kenntnisse erfordert, mit zusätzlichen sehr guten Kenntnissen im umfangreichen Gebiet DB-Zugriff.
Weiters erfordert es die Beherrschung relationaler Datenmodellierung - zB muss dir sonnenklar sein, was eine 1:n - Relation ist, eine m:n - Relation, und wie man das Tabellen-Layout eines Datenmodells im ER-Diagramm darstellt und plant.

fsonneborn schrieb:

Damit ist das DB Layout eigentlich schon klar.

Da irrst du dich glaub gewaltig. Jdfs. wenn es sich wirklich so verhält, dass du von relationaler Datenmodellierung und ER-Diagramm noch nie gehört hast.

(Achtung, es kommt wieder meine alte Leier:) Nach meiner Auffassung lernt man diese Dinge am besten ohne Datenbank, und wendet sich der Datenbank erst zu, wenn man in Sachen Datenmodellierung, ER-Diagramm, Databinding sattelfast ist, und die Anwendung in wesentlichen Zügen funktionsfähig ausprogrammiert und getestet hat.
Aber da wird mir immer energisch widersprochen, daher lasse ich stecken und überlasse dich an diesem Punkt anderen Anleitungen, die es vorziehen, von vornherein diese Technologien mit einzubeziehen.

Japp, da Widerspreche ich gleich mal.

Umgang mit der Datenbank lernt man am besten mit einer Datenbank.
Denn ich kann mir auf der Datenbank ganz einfach alle Ausgaben ansehen.

Wenn ich SELECT testen möchte kann ich das ohne großen Aufwand machen.

VB.net (oder C#, oder oder oder) ist später nur das Frontend der Anwendung. Das was der User sieht und bedient. Was noch eine gewisse Geschäftslogik mit aufweist und man kann hier schon direkt Fehler der User abfangen.

Wenn im Backend alles richtig designed ist kann ich ohne richtiges Frontend, zum Beispiel SQL Server Management Studio oder phpMyAdmin schon alles machen für was der User ein schickes Frontend erhält.

Hi,

diese sind nicht ausreichend. Der Gedanke dass sie es sind, zeigt dass du noch nicht annähernd Datenbänkerisch denkst! Hier rate ich zur Vorsicht. Durch soetwas verhaspelt man sich und es wird ein pures Gefrickel.

Du benötigst zumindest eine Tabelle für die Interessenten über die du verknüpfst. Wenn du sagst ihr habt bereits ein System mit den Informationen muss dort nicht viel drin stehen...
Die Nummer aus dem Hauptsystem sollte ausreichen und ggf. bestimmte Daten die sich eh im Laufe der Zeit ansammeln.
Du kommst in Teufels Küche wenn du die Interessenten nicht mehr auseinander halten kannst.
Man muss Daten strickt trennen und man muss immer in Verknüpfungen denken.
So wenig Daten wie möglich pro Tabelle und so viele wie nötig. Das Verknüpfen der Tabellen ist ja kein Teufelswerk.

Und ich halte wie der Erfinder NICHTS davon mit Datenbanken anzufangen und mit Select Gedönse rum zu spielen!!!
Im Studium und in der Ausbildung wird auch die Datenbank erst als ER-Modell gelehrt und das aus gutem Grund.

Erst einmal muss das Verständnis für die Funktionsweise her... Dann kommt die Bedienung. Und VS bietet einen genialen Designer (Access aber auch) für den man von der Terminologie der SQL-Aufrufe keine Ahnung haben muss. Hier reicht das reine Verständnis der Funktionsweise. Deshalb hat der EDR völlig Recht.

PS: Mitarbeiter ist nen Stamm kein Vertriebsgedönse (S_Mitarbeiter)
Wobei die Benamung Geschmackssache ist. Wichtig ist... überleg dir genau... ist es EINDEUTIG was ich da schreibe? Denn meist existieren so Programme lange und auch wenn du jetzt denkst es ist nur für Alquiese genutzt... Wenn erst einmal bekannt wird, dass etwas klappt wandert immer mehr in so Systeme. Ist Erfahrungssache Lieber immer offen gestalten. Damit verbaut man sich nix. Und die Mehrarbeit ist minimal.

Hast du dir die Tuts vom Erfinder mal angesehen?

EDIT:
Dein Aquisekunde soll mein Interessent sein, oder? Dann würde man grob doch mit den Tabellen auskommen. Ich würde aber den Adressstamm in jedem Fall hinzunehmen! Und die Dokumentation untergliedern über einen Stamm von Aktivitäten und daran erst die detaillierten Beschreibungen.
Zudem würde ich eine Bemerkung (die man an nem Interessent oder Ansprechpartner schreibt) trennen von einem neuen Dokumentationssatz. Ein neuer Dokumentationssatz kann eine Bemerkung verknüpft haben... aber es wird sicher auch mal nen "Nicht erreicht" ausreichen. Hierfür muss nicht zwingend ne Bemerkung angegeben werden. Hier reicht der Kopfsatz zu einer Aktivität, dass da was war und was da war... Solange es nicht mehr Informationen gibt.


EDIT2:
Und wenn du in den Kinderschuhen steckst. Schau dir die Tuts vom Erfinder an. Da siehst du was du wissen musst und was nicht. Bei Fragen gibts hier ja sicher Hilfe.
Im Grunde liegt dein Hauptproblem bei der Erstellung des Datenbankaufbaus. Der Zugriff darauf kommt danach.

- An den Grundlagen der Programmierung kommst du eh nicht vorbei -

MrTrebron schrieb:

Japp, da Widerspreche ich gleich mal.

Hihi - vielen Dank - auf dich ist Verlass

Jo, dann gib dem TE vlt. als erstes ein ER-Diagramm-Tool an die Hand, dass er sein Tabellen-Layout richtig planen kann. Bislang hat er ja nur eine Tabelle - oder meinst du, damit wird er auskommen?

@fsonneborn
In der Tat: Mitnichten und Tanten ist die DB-Struktur ausgereift.
Es gibt gerade in Vertrieb, Vertriebssteuerung und Vertriebsunterstützung Standards, die, wenn denn nicht umgesetzt, so doch zumindest bedacht werden sollten:
Vertriebsmethodiken im Überblick

Und die Miller-Heimann-Methode ist nach wie vor DIE Methode:
- organisiert
- transparent
- von Dritten fort-/weiterführbar (z.B. Urlaub/Krankheit)

Aus diesen Informationen der verschiedenen Methodiken sollten Projektergebnisse asl Anforderungsprofil definiert werden: Auch und gerade im halbprofessionellen/Hobby-Bereich der Entwicklung. Dazu gehören z.B. UNBEDINGT Entwürfe der Berichte, weil, nur vorhandenen und /oder bearbeitete Daten können dargestellt werden.

Mit diesem Gerüst können dann im Top-Down-Design stufenweise Detaillierungen vorgenommen werden (z.B. Erfassungsmasken, Strukturen der Datenhaltung).
Dazu gehören auch Entscheidungen, z.B.: Ist konkurrierende Bearbeitung durch mehrere Benutzer WIRKLICH nötig?

Als eine der letzten Stufen steht dann die Entscheidung, welches Datenbanksystem denn nun wirklich erforderlich ist, und DANN der endgültige Entwurf der Tabellen und deren Relationen zueinander.

Und nochmals der dringende Hinweis: Dokumentiere jede Entscheidung so, dass Du deren Gründe auch noch nach einigen Monaten nachvollziehen kannst.

Das Projekt ist sehr komplex, erfordert Durchhaltevermögen und wird Dich mehr asl einmal frustieren (also genaus die Dinge, die Du als Vertriebler täglich erfährst). Aber wenn Du das durchziehst, ist den Wissen und Können um Größenordnungen gesteigert.

Ich glaube, dieses Forum wird Dich nach Kräften unterstützen.

Ja so bin ich.

Das er sein Datenbankmodell vorher entwirft sollte klar sein. Ich kann nicht anfangen irgendwas anzulegen.

Hier setzte ich aber, berufsbedingt, Requirements Engineering voraus. Daraus leitet sich dann ab was gemacht werden soll, davon wiederum wie umgesetzt wird.

Prozessdiagramme sollten erstellt werden um die Abläufe klar zustellen
Bevor eine Zeile Code geschrieben wird muss das DB Modell stehen. Welche Views und Prozeduren soll es geben.
Welche Objekte werden im Frontend gebraucht, Methoden und Properties.
Wie soll das Frontend aussehen. Skizzen.
Es sollten Use Cases definiert werden um hinterher zu testen ob die Funktionen so implementiert wurden wie es gewünscht wurde.
Also werden aus des Use Cases Test Cases.

Hi,

V_Mitarbeiter
S_Branche
S_Aquisekunden
S_Aquisekunden_Mitarbieter
V_Dokumentation

Wenn das die finale Lösung ist, dann Prost Mahlzeit. Wenn du die Postings mit Ratschlägen die dir hier wirklich helfen ignorierst weil dir der Lernaufwand auf den ersten Blick zu anstrengend erscheint, dann tut's mir Leid für dich. Anhand deiner gewählten Datenbankstruktur sieht man doch gleich dass du von -wie EDR schon sagte- relationaler Datenmodellierung noch nie was gehört hast. Genauso wenig wie du nicht weißt dass Redundanzen vermieden werden sollen durch Einhaltung der Normalformen die sich auf deine Struktur am besten anwenden lassen.

ich wollte mich schon immer etwas genauer mit vb.net beschäftigen

Klingt also als könntest du so lala VB und hast noch weniger Ahnung von Datenbanken. Eine äußerst ungünstige Mischung was dein aktuelles Vorhaben betrifft.

Das Tool soll wirklich nur Dokumentationszwecken dienen und sich lediglich auf "Akquisekunden" beziehen. Für Stammkunden gibt's entsprechende Systeme.

Wieso nicht das eine mit dem anderen verbinden? Sodass später für einen Stammkunden der Werdegang der Kundengewinnung gleich mit dokumentiert ist, was den geilen Nebeneffekt hat dass sich so statistische Auswertungen aufstellen lassen, anhand derer man Strategien zur Gewinnung weiterer Kunden entwickeln könnte.

Umgang mit der Datenbank lernt man am besten mit einer Datenbank.

Ja bestimmt. Nicht. Außer du willst SQL-Befehle wie SELECT und INSERT auswendig lernen und ansonsten weiterhin von Datenbanken an sich keine Ahnung haben.

Prozessdiagramme sollten erstellt werden um die Abläufe klar zustellen
Bevor eine Zeile Code geschrieben wird muss das DB Modell stehen. Welche Views und Prozeduren soll es geben.
Welche Objekte werden im Frontend gebraucht, Methoden und Properties.
Wie soll das Frontend aussehen. Skizzen.
Es sollten Use Cases definiert werden um hinterher zu testen ob die Funktionen so implementiert wurden wie es gewünscht wurde.
Also werden aus des Use Cases Test Cases.

Sorry aber das klingt für mich als hättest du die Wörter aufgeschnappt oder gegoogelt ohne selbst einen Plan zu haben was du da eben geschrieben hast. "Welche Objekte werden im Frontend gebraucht, Methoden und Properties." bitte was?


@TE:
Ich sag das ja nur weil ich weiß wie böse du mit deiner Einstellung auf die Fresse fliegen wirst. Der Aufwand für das Projekt das du im Kopf hast ist nicht unerheblich - und wenn du jetzt keine solide Grundlage schaffst, garantiere ich dir dass du es binnen kurzer Zeit abbrechen wirst und vielleicht mehrmals von vorn beginnen musst. Mach es von Anfang an richtig oder lass es. Hintergründe und Zusammenhänge sind wichtig! Klar erzielt man mit Drauflos-Programmieren schnellere Ergebnisse - aber das sollte nicht dein Bestreben sein, denn diese Ergebnisse sind dann weder gut, noch hast du am Ende eine Ahnung was du da gemacht hast. Es richtig zu machen ist nicht so viel Aufwand wie du denkst


Link

@Link Schon mal eine Anwendung professionell entwickelt?
Es steckt viel Arbeit vor der eigentlichen Arbeit in einer Software.

Und bevor ich "Datenbänkerei" in einem Dataset übe oder üben lassen gebe ich den Leuten lieber eine vernünftige und flexible IDE dafür zur Hand.
Das man vorher grundsätzliches verstehen muss ist mir schon klar.

Nachtrag an den TE: Ich möchte auch nch mal meine Bedenken äußern das du dich da verrennst wenn du es dir zu einfach machen möchtest. Überlege genau welche Daten gespeichert werden sollen und versuche dann die einzelnen Tabellen weiter in einzelne Tabellen zu zerlegen wenn es Redundanzen in den Tabellen gibt. Das nennt man Normalisierung. Des weiteren Schreibe oder noch besser zeichne auf wie der spätere Bearbeitungsablauf sein soll. Das wäre dann dein Prozess.

Die VB.net Bücher von Galileo (jetzt Rheinwerk) kommen hier nciht so gut an.
Leider folgen die Bücher nicht ganz konsequent der .net Idee.

Der @ErfinderDesRades schwört auf ein Buch vom Autor Löffelmann, welches man hier kostenlos beziehen kann. Ich habe mal in einigen Kapiteln geblättert und es macht einen guten Eindruck.
Des weiteren gibt es noch Datenbank-Programmierung mit Visual Basic. Dies setzt aber Grundlegendes VB und DB wissen voraus.

Ich kann immer die MSDN ans Herz legen. Das ist meine Hauptinformationsquelle. Denn da gibts echt fast alles. Zudem ist der Objectbrowser ein geniales Werkzeug. Aber darauf geht der Erfinder glaube ich auch ganz intensiv ein.

Für spezifische Rückfragen sind wir hier aber auch immer dankbar. Gerade wenn es auch für andere Leser zu einer am Ende funktionierenden Lösung führt.
Also es ist immer schön wenn hier auch die Informationen und die Fortschritte die du machst ersichtlich werden. Das hilft anderen mit gleichem Problem sehr.

jo, ObjectBrowser und so: ...

Ach - arbeite am besten ganz ganz sorgfältig, jeden einzelnen Link von Datenverarbeitungs-Vorraussetzungen durch.

Das fängt an mit Vb.net-Grundeinstellungen, Fachbegriffe, ObjectBrowser und mehr, Buch, Datenbänkerei-Theorie, Datenbänkerei-Praxis (mit Dataset), Forms-Layout, etc blabla...

Es ist alles fundamental wichtig - lass nix aus, sei bei nix schlampig.