AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Kauf- und Kontenverwaltung - Datenbank notwendig?

Kauf- und Kontenverwaltung - Datenbank notwendig?

Ein Thema von Asura · begonnen am 2. Dez 2017 · letzter Beitrag vom 14. Jan 2018
Antwort Antwort
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#1

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 18:35
Ich habe mich mal an den Access-Versuch ran gemacht.
Funktioniert super, schnell und einfach! Verbindung ist aufgebaut, testweise eine Tabelle als Form in das Programm und er zeigt mir direkt die Einträge in der Datenbank an, die ich vorher über Access hinzugefügt habe.

Ein paar Verständnisfragen kamen hier dennoch auf:

  1. Mir ist nur gerade aufgefallen, wenn ich über das Programm auf die Datenbank zugreife und ich nebenbei einen Eintrag mache und dann die Datei abspeichere, müsste es doch zu Überschneidungen kommen? Nach dem Motto: Das Programm möchte die Datei ändern, durch eine Eintragung, aber ich speichere eine ältere Datenbank ab, um meine neue Änderung manuell zu verwirklichen.

  2. Und liege ich da richtig, wenn ich später mein Programm auf dem Tablet habe, darauf ja auch die Datenbank, damit das Programm darauf zugreifen kann, aber diese Datenbank in einem Cloud-Ordner sich befinden muss, damit ich über meinen Computer auf die Datenbank zugreifen kann?

  3. Kann man eigentlich, solche Komponenten wie ADOConnection etc. irgendwie nicht auf der Form haben? Ich habe die schlichtweg auf die Form gelegt, aber ich finde das eher unschön.

  4. Des Weiteren habe ich nun die Komponenten ADOConnection, ADOTable und Datasource, reicht dies für mein Vorhaben?
    Also auch hier wieder: Sehe ich das richtig, wenn ich bei mehreren Tabellen zur Laufzeit einfach nur den Tablename von ADOTable ändern muss, um damit zu arbeiten?

  5. Mir ist noch was aufgefallen, trotzt der neuesten Version von Delphi kann ich nicht die neueste Version von Access Dateien nutzen (accdb), sondern muss auf (mdb) zurückgreifen, woran liegt das?

Geändert von Asura (12. Dez 2017 um 18:38 Uhr)
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.600 Beiträge
 
Delphi 7 Professional
 
#2

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 19:16
Ich habe mich mal an den Access-Versuch ran gemacht.
Funktioniert super, schnell und einfach! Verbindung ist aufgebaut, testweise eine Tabelle als Form in das Programm und er zeigt mir direkt die Einträge in der Datenbank an, die ich vorher über Access hinzugefügt habe.

Ein paar Verständnisfragen kamen hier dennoch auf:

  1. Mir ist nur gerade aufgefallen, wenn ich über das Programm auf die Datenbank zugreife und ich nebenbei einen Eintrag mache und dann die Datei abspeichere, müsste es doch zu Überschneidungen kommen? Nach dem Motto: Das Programm möchte die Datei ändern, durch eine Eintragung, aber ich speichere eine ältere Datenbank ab, um meine neue Änderung manuell zu verwirklichen.
Du schriebst: Ein Gerät, ein Benutzer.
Da musst Du Dich dran halten.
Entweder mit dem Programm auf die Datenbank zugreifen, oder mit Access oder mit Delphi, aber nicht mit allen dreien gleichzeitig, das sind dann mehrere Benutzer und Du musst Dir Gedanken über ein Mehrbenutzerkonzept machen, wenn jede Software zeitgleich was ändern soll. Ggfls. gewinnt, wer zuletzt eine Datenänderung schreibt.
Und liege ich da richtig, wenn ich später mein Programm auf dem Tablet habe, darauf ja auch die Datenbank, damit das Programm darauf zugreifen kann, aber diese Datenbank in einem Cloud-Ordner sich befinden muss, damit ich über meinen Computer auf die Datenbank zugreifen kann?
Du musst die Datenbank dann irgendwie vom Tablet zu PC bekommen (und auch wieder zurück) oder dafür sorge tragen, dass sie an einer Stelle liegt, an der beide Systeme darauf zugreifen können. Aber dabei dürfen dann keine lokalen Kopieen existieren, sonst gehen ggfls. Änderungen verloren, weil die Kopieen ja nicht inhaltlich synchronisiert werden.
Kann man eigentlich, solche Komponenten wie ADOConnection etc. irgendwie nicht auf der Form haben? Ich habe die schlichtweg auf die Form gelegt, aber ich finde das eher unschön.
Ja kann man, man muss sie zur Laufzeit erstellen. Damit geht dann der Komfort der Entwicklungsumgebung verloren. Und stören die in der Entwicklungsumgebung wirklich so arg?
Des Weiteren habe ich nun die Komponenten ADOConnection, ADOTable und Datasource, reicht dies für mein Vorhaben?
Also auch hier wieder: Sehe ich das richtig, wenn ich bei mehreren Tabellen zur Laufzeit einfach nur den Tablename von ADOTable ändern muss, um damit zu arbeiten?
Scheint so, sonst würde das, was Du hast, ja nicht funktionieren. Ohne genaue Beschreibung dessen, was Du denn nun jetzt wirklich vorhast, kann man da nicht zu vielem Raten. Sollen immer nur die Daten aus einer Tabelle angezeigt werden oder ggfls. auch mal aus mehreren Tabellen? Sollen Inhalte einer Tabelle ggfls. als Nachschlagwerte für andere Tabellen dienen ...
Mir ist noch was aufgefallen, trotzt der neuesten Version von Delphi kann ich nicht die neueste Version von Access Dateien nutzen (accdb), sondern muss auf (mdb) zurückgreifen, woran liegt das?
Das liegt nicht an Delphi, sondern an dem genutzten Datenbanktreiber.
Siehe: https://support.office.com/de-de/art...c-7528b9f074b6

Benötigst Du für Deine Anwendung alles das, was accdb zusätzlich zu mdb bietet?

Überleg' Dir bitte zuerst, was Du genau machen möchtest und halte das irgendwie fest. Dann kannst Du gezielt fragen, was Du wie genau umsetzen kannst. Mit dem bisherigen Input ist eine effektive Hilfestellung nicht möglich.
  Mit Zitat antworten Zitat
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#3

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 21:26
Gut, ich habe mir überlegt, dass ich über eine Ini-Datei, den Zugriff solange verweigere auf die Software, wenn ich diese Datenbank über meinen Computer bearbeite.

Nun frage ich mich, wie ich nun ein Datensatz abfrage, so kann ich ja theoretisch über SQL eine Spalte abfragen, doch wie kann ich die Abfrage in ein Stringlist fassen?
Code:
 with ADOQuery do
  begin
    Close;
    SQL.Clear;
    SQL.Add('SELECT username FROM users') ;
    Open;
  end;
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.600 Beiträge
 
Delphi 7 Professional
 
#4

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 21:50
Weiß zwar nicht, was Du vorhast, eventuell sowas?
Delphi-Quellcode:
var
  sl : TStringList;
begin
  sl := TStringList.Create;
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username FROM users') ;
  ADOQuery.Open;
  while not ADOQuery.EoF Do begin
    sl.Add(ADOQuery.Fields[0].AsString);
    ADOQuery.Next;
  end;
  ADOQuery.Close;
  // Irgendwas mit der Stringliste machen.
  ...
  sl.Free;
end;
Statt 'ner Stringliste könnte man dort auch von 'ner TComboBox die Eigenschaft Items nehmen. Dann sieht die entsprechende Zeile so aus:ComboBox1.Items.Add(ADOQuery.Fields[0].AsString); An Stelle von  sl := TStringList.Create; wäre dann eher ein ComboBox1.Items.Clear; angebracht.
  Mit Zitat antworten Zitat
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#5

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 22:03
Ich würde gerne die existierenden Benutzer in Button.Caption speichern. Hatte das vorher ebenfalls mit Ini-Dateien gelöst, hat auch wunderbar geklappt (Buttons, weil ein Tablet und größere Buttons mit Benutzer-Auswahl angenehmer ist als eine Combobox beispielsweise).

Leider stößt er mit deinem Beispiel folgende Fehlermeldung aus:
"1 Parameter wurde erwartet, aber es wurden zu wenige Parameter übergeben".

Habe die Stringlist nur über ein Showmessage ausgeben wollen, um zu sehen, ob es funktioniert.
Ich habe auch überprüft die Verbindung von ADOQuery zu DataSource steht, sowie auch die Verbindung von DataSource zu ADOTable, also in den Objektinspektor ist alles richtig eingestellt. Komischerweise hat es ja auch mit dem Grid wunderbar funktioniert!
  Mit Zitat antworten Zitat
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#6

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 22:25
Des Weiteren habe ich mir mal bisschen mehr Gedanken zu der Datenbankmodellierung gemacht und bisschen auch mich weiter informiert über Datenbanken.

Nun möchte ich Fragen, ob hier ein Denkfehler drin ist:

Es existieren 3 Tabellen: Getränke, Bestellungen, Users

Getränke <-- n --- m --> Bestellungen <-- n --- 1 --> Users

Tabelle Getränke hat die Attribute:

Getränkename (Primärschlüssel)
Preis

Tabelle Bestellungen hat die Attribute:

Bestellt_Nr (Primärschlüssel)
Datum (Sekundärschlüssel)
UserID (Fremdschlüssel)
Getränkename (Fremdschlüssel)

Tabelle Users hat die Attribute:

UserID (Primärschlüssel)
User
Guthaben

Ist das so korrekt?

Nun noch eine Frage: Wie löse ich das, dass Bestellungen mehrere Getränke notiert und hierbei die einzelnen Getränke mit Anzahl und Preis berücksichtigt.
Lass mich raten: Mehr Tabellen und Verknüpfungen?

Ich möchte noch mal eventuell kurz Erklären was mein Vorhaben ist, damit man sich besser hineinversetzen kann:
Stellen Sie sich vor, Sie können hier einfach über ein Tablet Ihr Konto auswählen. Daraufhin öffnet sich eine Übersicht, wo verschiedene Getränke zur Auswahl stehen mit Preis (Also Konto, Getränke und Preis können variabel über die Datenbank geändert werden und werden auch so vom Programm immer mit verändert). Daraufhin kann man Beispielsweise: Zwei Bier und Zwei Cola auswählen und es wird in einen virtuellen Warenkorb gelegt. Danach drückt man nur noch Kauf abschließen und das System rechnet automatisch nach der Buchung ein Minusbetrag (Hier in der Tabelle User unter Guthaben) den Preis runter und registriert für eine spätere Einsicht immer noch (unter Tabelle Bestellungen) die komplette Bestellung.
So kann ich durch ein Programm schlichtweg Lagerbestände kontrollieren, der User hat hier immer eine Übersichtsmöglichkeit und die Sicherheit, dass keine Verrechnungen stattfinden.

Hoffe nun kommt mein Vorhaben besser rüber.
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.600 Beiträge
 
Delphi 7 Professional
 
#7

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 23:34
Du schriebst 16 Nutzer. Folgt daraus 16 Buttons?

Wenn ja, dann sowas? (Dabei gehen wir mal davon aus, dass die Buttons Button1 bis Button16 heißen.)
Delphi-Quellcode:
var
  i : Integer;
  btn : TButton;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;
  ADOQuery.Open;
  i := 0;
  while not ADOQuery.EoF Do begin
    i := i + 1;
    // So kurz ist das mutig. Man sollte im "richtigen" Programm dann prüfen,
    // ob die Komponente auch gefunden wurde und ob der Typ passt.
    btn := TButton(Self.FindComponent('Button' + IntToStr(i)));
    if Assigned(btn) then begin
      btn.Caption := ADOQuery.Fields[0].AsString;
      // Nur als Idee: Der Button "weiß" dann direkt die UserID für die weitere Arbeit.
      // Beim Button-Click muss man dann nicht erst aus dem Namen in der Caption
      // die UserID suchen, um sie für die Tabelle Bestellungen verwenden zu können.
      btn.Tag := ADOQuery.Fields[1].AsInteger;
    end else begin
      // Das sollte nicht vorkommen, aber eine entsprechende Fehlerbehandlung
      // wäre trotzdem nicht schädlich.
    end;
    ADOQuery.Next;
  end;
  ADOQuery.Close;
end;
Zum Datenmodell:

Der Getränketabelle würd' ich zusätzlich eine Getraenke_ID gönnen und die als Primärschlüssel nehmen.

Die Tabelle Bestellungen erhält dann statt des Getränkenamens die Getränkeid.

Mit dem Modell kann man eigentlich schon pro Bestellung mehrere Getränke verwalten. Es werden dann pro Bestellung mehrere Datensätze angelegt. Man könnte, damit es übersichtlicher wird, der Getränketabelle noch eine Spalte Position spendieren. Jedes Getränk zu einer Bestellung bekommt eine eigene Position, so dass man aus Bestellt_Nr und Position einen eindeutigen Schlüssel machen könnte. Auch kann man hierüber die Ausgabe immer sortiert ausgegeben werden und hat immer die gleiche Sortierung, selbst dann wenn man mal die Getränkenamen ändern sollte.

Umlaute in Tabellen- und Spaltennamen finde ich kritisch. Man weiß nie genau, ob man das auch (wenn nötig) auf eine andere Datenbank übertragen kann. Persönlich nehme ich nur (auch wenn Datenbanken was anderes können) nur die Buchstaben A bis Z, die Ziffern 0 bis 9 und den Unterstrich _. (Mag altmodisch sein, aber bisher hat noch jeder Datenbankwechsel ohne Programmänderungen oder Änderungen am Datenmodell funktioniert. Tabellen und Spaltennamen sind bei mir maximal 30 Zeichen lang. In der Regel reicht das auch aus.
  Mit Zitat antworten Zitat
Antwort Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz