Kauf- und Kontenverwaltung - Datenbank notwendig?

[Asura]

Zitat von Delphi.Narium:

Bezgl.: WIDEMEMO

Für Namen nimmt man kein Memofeld sondern 'nen String bzw. VarChar. Wie lang kann den ein "gewöhnlicher" Username werden? VarChar(250) wäre da wohl schon eher überdimensioniert. In eine Memo- bzw. Blobfeld passt notfalls auch ein ganzer Roman rein, das scheint mir doch eher reichlich übertrieben.

Könntest Du eventuell mal die Createstatements Deiner Tabellen hier posten? Dann kann man da nochmal drüberschauen, inwieweit Bedeutung und Typ der Spalten zusammenpassen. Das ist was, da kann man am Anfang schonmal sehr leicht was falsch wählen und bereut nachher, dass eine Umstellung ohne Datenverlust nicht mehr so leicht möglich ist.

Die Tabellenerstellung würd' ich insgesamt auf Dauer lieber mit dem Programm (oder einem extra Pflegeprogramm?) selbst machen. Geht auch über 'ne ADOQuery und deren Methode ExecSQL. Vorteil: Die MS-Access-typischen "Unsitten" bei der Tabellendefinition kann man dadurch umgehen (kann sich also an den SQL-Standard halten, was einen ggfls. mal notwendig werdenden Datenbankwechsel vereinfacht), außerdem bekommt man (so meine ich) ein besseres Gefühl für die Tabellendefintionen und deren Abhängigkeiten untereinander. Aber das ist sicherlich auch Geschmacksache.

Ich konnte das Problem lösen, indem ich die Einstellung auf einen Short String geändert habe habe.

Bezüglich des Pflegeprogramms, wollte ich eh entwerfen, da ich gerne doch eine Option hätte SQL Befehle auszuführen. Doch habe ich gerade Probleme mit der Verbindung, dass er das Ergebnis auf die das Grid überträgt. Muss man nicht die Tabelle dafür schließen und dann das Datasource an das Query anhängen?
Wie würde das dann auch mit der Formatierung aussehen wegen SQL? Benutze ein Memofeld, dort trage ich den SQL Befehl ein und über ADOQuery.Text setze ich den Text rein.

[Delphi.Narium]

Zum Anzeigen der Ergebisse eines SQLs braucht man eigentlich nur:

Ein Memo für die Texteingabe.
Eine ADOQuery, 'ne DataSource und ein DBGrid. DBNavigator ist ein kann. Eventuell 'ne Statusbar mit SimplePanel := True;

Einen Button, der ungefähr so einen Quelltext im OnClick enthält (ungetestet):

Delphi-Quellcode:

var
  s : String;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  // Wenn selektierter Text vorhanden ist, wird nur der als SQL übernommen.
  // Dadurch kann man dann im Memo mehrere SQLs haben und muss nicht immer alle neu schreiben ;-)
  // Speichert man mit Memo.Lines.SaveToFile beim Programmende
  // und lädt beim Programmstart mit Memo.Lines.LoadFromFile, hat man auch länger was davon.
  if Memo.SelAvail then begin
    ADOQuery.SQL.Add(Trim(Memo.SelText));
  end else begin
    ADOQuery.SQL.Add(Trim(Memo.Text));
  end;
  if ADOQuery.SQL.Count = 0 then exit;
  Try
    s := AnsiLowerCase(Copy(ADOQuery.SQL[0],1,6);
    if s = 'select' then begin
      ADOQuery.Open;  // Für Abfragen
      StatusBar.SimpleText := Format('Es wurden %d Datensätze gefunden.',[ADOQuery.RecordCount]);
    end else begin
      ADOQuery.ExecSQL; // Für alles andere wie Insert, Update, Delete, Create Table ...
      StatusBar.SimpleText := Format('Von der Abfrage waren %d Datensätze betroffen.',[ADOQuery.RowsAffected]);
    end;
  except
    on e : Exception do begin
      MessageDlg(e.Message,mtError,[mbOk],0);
    end;
  end;
end;

Man kann zur Laufzeit bei 'ner DataSource den DataSet ändern, allerdings gehe ich her, dass ich jeder Query, Table (wenn ich die denn mal brauche) 'ne eigene DataSource spendiere und jeweils ein eigenes DBGrid ...

Normalerweise haben aber die "Pflegeteile" von Programmen nur eine Datenbankverbindung, eine Query, eine DataSource, ein DBGrid und einen DBNavigator. Das reicht, da man alles per SQL machen kann, was zur Datenanzeige und / oder Datenmanipulation erforderlich ist.

Mehrere Querys und/oder Tables gibt es nur, wenn unumgänglich mehrer Datenmengen zeitgleich zur Verfügung stehen müssen, bei einem Pflegeprogramm scheint mir dies nicht sinnvoll zu sein.

[Asura]

Vielen Dank für die Mühe!

Bezüglich Memo.SelAvail musste ich leider feststellen existiert nicht, habe die auch nicht hierunter http://docs.embarcadero.com/products...rls_TMemo.html gefunden.

Wie wäre es mit:

Delphi-Quellcode:

  if SQLEingabe.SelLength <> 0 then begin
    ADOQuery.SQL.Add(Trim(SQLEIngabe.SelText));
  end else begin
    ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
  end;

Aber generell tut sich effektiv nichts im Memo. Ich gehe mal davon aus, dass es bestimmt an der Verlinkung der ADO Komponenten liegt.
Du hast geschrieben, dass man nur eine Verbindung, Query, Datasource und DBGrid benötigt? Also kein ADOTable?
Wie würde dann die Verbindung aussehen zwischen den Komponenten?
Weil benötigt DataSource nicht die Komponenten ADOTable ?

[jobo]

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

[Delphi.Narium]

Zitat von jobo:

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

Oh Mist, hab' ich nicht dran gedacht, da ich fast nur noch SynEdit nutze.

@Asura
ADOTable ist für die statische Anzeige eines Tabelleninhaltes, ADOQuery für die Ausführung von SQL-Statements.

DataSource benotigt ein TDataSet, ADOQuery und ADOTable sind beide von TDataSet abgeleitet, funktionieren also beide.

Einfach mal von beiden eins aufs Formular pappen, 'ne DataSource dazu und im Objektinspektor zum DataSource bei DataSet schauen, was da so zur Auswahl steht. Alles was da angezeigt wird, kann man auch nutzen.

Bezüglich Deiner Alternative zum SelAvail: Ja, das geht auch so, mit SelText bekommst Du ja den markierten Text. Wie und ob das bei unterschiedlichen Komponenten unterschiedlich funktioniert ist ja eher nachrangig, Hauptsache: Ziel erreicht

Das Memo ist für die Eingabe von SQLs. Dort tut sich nichts, außer Du gibst dort was ein. Deine Eingabe wird dann an die ADOQuery weitergereicht und nach deren öffnen, mit Hilfe einer DataSource und den dieser zugeordneten Datenkomponente (z. B. einem DBGrid), angezeigt.

Mal einen nicht wirklich sinnvollen Quelltext, mit dem man das demonstrieren könnte:

Delphi-Quellcode:

ADOQuery.Close;
ADOTable.Close;
ADOTable.TableName := 'users';
DataSource.DataSet := ADOQuery;
ADOQuery.SQL.Text := 'select * from users where ID = 1';
ADOQuery.Open;
ShowMessage('Sieht man jetzt den User mit der ID 1?');
ADOQuery.Close;
ADOTable.Open;
ShowMessage('Sieht man jetzt alle User?');
ADOTable.Close;

Dieser Quelltext ist so in etwa für eine Demonstration geeignet, aber nicht für den wirklichen Betrieb.

Wenn ich etwas benötige, um beliebige Daten anzuzeigen, nutze ich nie eine ADOTable, sondern immer nur ADOQuery (bzw. bei anderen Datenbankkomponenten die entsprechenden Gegenstücke). Will ich alle Daten einer Tabelle sehen, dann ist die Abfrage eben Select * from ebendertabelledieichsehenwill.

Ein Hin und Her per Zuweisung von diversen DataSet-Nachkommen zu eine DataSource macht nur den Quelltext verwirrend und scheint mir nicht zielführend.

Mal eben wild zusammengedaddelt so eine Art "Demo"

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, DB, ADODB, ExtCtrls, DBCtrls, Grids, DBGrids, ComCtrls;

type
  Tfrm = class(TForm)
    DataSource: TDataSource;
    ADOQuery: TADOQuery;
    pnTop: TPanel;
    StatusBar: TStatusBar;
    DBGrid: TDBGrid;
    DBNavigator: TDBNavigator;
    Splitter: TSplitter;
    ADOConnection: TADOConnection;
    btnSQL: TButton;
    btnEnde: TButton;
    pnInfo: TPanel;
    SQLEingabe: TMemo;
    Splitter1: TSplitter;
    Tabellen: TMemo;
    procedure btnEndeClick(Sender: TObject);
    procedure btnSQLClick(Sender: TObject);
    procedure TabellenDblClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  frm: Tfrm;

implementation

{$R *.dfm}

procedure Tfrm.btnEndeClick(Sender: TObject);
begin
  ADOQuery.Close;
  ADOConnection.Close;
  Close;
end;

procedure Tfrm.btnSQLClick(Sender: TObject);
var
  slTables : TStringList;
  slFields : TStringList;
  i        : Integer;
  k        : Integer;
begin
  if not ADOConnection.Connected then begin
    if ADOConnection.ConnectionString = '' then begin
      ADOConnection.ConnectionString := PromptDataSource(handle,'');
    end;
    if ADOConnection.ConnectionString <> '' then begin
      ADOConnection.Open;
      Tabellen.Lines.Clear;
      slTables := TStringList.Create;
      slFields := TStringList.Create;
      ADOConnection.GetTableNames(slTables,false);
      for i := 0 to slTables.Count - 1 do begin
        Tabellen.Lines.Add(slTables[i]);
        ADOConnection.GetFieldNames(slTables[i],slFields);
        for k := 0 to slFields.Count - 1 do begin
          Tabellen.Lines.Add(Format('  %s',[slFields[k]]));
        end;
      end;
      slTables.Free;
      slFields.Free;
    end;
  end;
  if ADOConnection.Connected then begin
    ADOQuery.Close;
    ADOQuery.SQL.Clear;
    if SQLEingabe.SelLength <> 0 then begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.SelText));
    end else begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
    end;
    if Trim(ADOQuery.SQL.Text) <> '' then begin
      ADOQuery.Open;
    end;
  end;
end;

procedure Tfrm.TabellenDblClick(Sender: TObject);
begin
  if Tabellen.SelText <> '' then begin
    SQLEingabe.SelText := Tabellen.SelText;
  end;
end;

procedure Tfrm.FormCreate(Sender: TObject);
begin
  if FileExists(ChangeFileExt(Application.ExeName,'.sql')) then begin
    SQLEingabe.Lines.LoadFromFile(ChangeFileExt(Application.ExeName,'.sql'));
  end;
end;

procedure Tfrm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  SQLEingabe.Lines.SaveToFile(ChangeFileExt(Application.ExeName,'.sql'));
end;

end.

Und das Formular dazu:

Delphi-Quellcode:

object frm: Tfrm
  Left = 4
  Top = 4
  Width = 1000
  Height = 640
  Caption = 'Demo-Datenbankoberfläche ;-)'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  OnClose = FormClose
  OnCreate = FormCreate
  PixelsPerInch = 96
  TextHeight = 13
  object Splitter: TSplitter
    Left = 0
    Top = 265
    Width = 992
    Height = 8
    Cursor = crVSplit
    Align = alTop
    Beveled = True
  end
  object pnTop: TPanel
    Left = 0
    Top = 0
    Width = 992
    Height = 41
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 0
    object btnSQL: TButton
      Left = 8
      Top = 8
      Width = 97
      Height = 25
      Caption = '&SQL ausführen'
      TabOrder = 0
      OnClick = btnSQLClick
    end
    object btnEnde: TButton
      Left = 112
      Top = 8
      Width = 75
      Height = 25
      Caption = '&Ende'
      TabOrder = 1
      OnClick = btnEndeClick
    end
  end
  object StatusBar: TStatusBar
    Left = 0
    Top = 594
    Width = 992
    Height = 19
    Panels = <>
  end
  object DBGrid: TDBGrid
    Left = 0
    Top = 273
    Width = 992
    Height = 296
    Align = alClient
    DataSource = DataSource
    TabOrder = 2
    TitleFont.Charset = DEFAULT_CHARSET
    TitleFont.Color = clWindowText
    TitleFont.Height = -11
    TitleFont.Name = 'MS Sans Serif'
    TitleFont.Style = []
  end
  object DBNavigator: TDBNavigator
    Left = 0
    Top = 569
    Width = 992
    Height = 25
    DataSource = DataSource
    Align = alBottom
    TabOrder = 3
  end
  object pnInfo: TPanel
    Left = 0
    Top = 41
    Width = 992
    Height = 224
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 4
    object Splitter1: TSplitter
      Left = 697
      Top = 0
      Width = 8
      Height = 224
      Beveled = True
    end
    object SQLEingabe: TMemo
      Left = 0
      Top = 0
      Width = 697
      Height = 224
      Align = alLeft
      TabOrder = 0
    end
    object Tabellen: TMemo
      Left = 705
      Top = 0
      Width = 287
      Height = 224
      Align = alClient
      TabOrder = 1
      OnDblClick = TabellenDblClick
    end
  end
  object DataSource: TDataSource
    DataSet = ADOQuery
    Left = 632
    Top = 48
  end
  object ADOQuery: TADOQuery
    Connection = ADOConnection
    Parameters = <>
    Left = 560
    Top = 48
  end
  object ADOConnection: TADOConnection
    Left = 472
    Top = 48
  end
end

Im realen Leben sollte man allerdings nicht gänzlich auf jedwede Fehlerbehandlung verzichten.

[Asura]

Moin Moin,
nachdem ich erfolgreich nun mein Projekt mit Access beendet habe widme ich mich nun einem neuen Projekt.
Nun möchte ich aber nicht mehr mit Access arbeiten, sondern nun auf eine Datenbank zurückgreifen, die mit einem Server dann gehalten wird.

Ich bin nun auf der Suche nach Anbietern, die günstig Datenbankserver anbieten.
Bis ich einen gefunden habe, würde ich jedoch gerne schon mal beginnen. Welche Lösung wäre die Beste, um direkt eine Schnittstelle zu haben ohne groß im Programmcode was ändern zu müssen.
Eventuell in Richtung Homeserver?
Die Datenbankmodellierung habe ich bereits fertig, wenn man da noch mal rüber schauen könnte und eventuell Verbesserungsvorschläge

[Delphi.Narium]

Mein Vorgehen ist erstmal:

Connectionstring auf die neue Datenbank ändern und Programm starten.
Wenn's nicht geht (was äußerst selten ist) muss ich halt die Probleme beheben.

Wenn man sich bei den SQLs an den Standard hält, sind Probleme eher selten, ab und an werden Datentypen etwas anders gehandhabt, aber die Masse sollte einfach laufen.

[edit - etwas provokant]
Wenn man mit Delphi eine gute Datenbankapplikation geschrieben hat, ist es der egal, gegen welche Datenbank sie läuft, man ändert die Datenbankverbindung (gerne per Dialog) und das Programm läuft gegen eine andere Datenbank. Der Softwareentwickler muss die Datenbanken nicht mal alle kennen.

Klar: Auf Datenbankseite darf man dann nur das nutzen, was alle Datenbanken können. Dafür gibt es den Standard, der weitgehend eingehalten wird.

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.
[/edit]