Problem Auslesen von MySQL und Ausgabe in ListViews

[Vienesko]

Moin moin,

ich habe ein Problem mit einer MySQL Datenbank in der Verbindung mit der Ausgabe in eine ListView.
Ich suche schon den ganzen Tag nach hilfreichen Threads im Internet aber mir fallen keine passenden Stichwörter ein. Deshalb versuche ich es jetzt mal so.

Kurze Erklärung was passieren soll: Ich habe eine Datenbankoberfläche programmiert, die diverse Editfelder, Buttons und auch 3 Listviews enthält. ListView1 enthält Artikel mit Preisen etc (Artikelstamm; Name: "barcodes"), ListView2 enthält einige, ausgewählte Einträge der 1. ListView (wie ein digitaler Kühlschrank; Name: "inhouse") und ListView 3 soll später ein Einkaufszettel werden, auf den man auch Einträge aus dem Artikelstamm hinzufügen kann usw (Name: "ekz"). Aber da bin ich noch nicht. Datenbanktechnisch ist das ganze über eine MySQL Datenbank mit derzeit 3 Tabellen gelöst.

So nun zu meinem Problem:
Bei Programmstart (später auch dynamischer) soll das Programm den Inhalt aller drei Tabellen in die jeweiligen ListViews schreiben. Mit der ListView1, also der Stammdatenbank, geht das auch wunderbar. Gibt mir alle Einträge aus. Sobald ich aber die Statements für ListView2 hinzufüge, schmeisst er mir mein Programm komplett durcheinander bis hin zur Startverweigerung. In mySQL kommen die Daten aber an. Es geht nur um Übertragen in die ListView.

Ich wette, es ist eigentlich ganz einfach aber manchmal verbeisst man sich da so und findet seinen Fehler nicht. Da wäre ich für eure Hilfe sehr dankbar. Hier die betreffenden Zeilen:

Delphi-Quellcode:

/bei Programmstart auslesen der Datenbank "barcodes"
SQLQuery1.SQL.Clear;
SQLQuery1.Params.Clear;
SQLQuery1.SQL.Text:= 'SELECT ID,Produktname,Hersteller,Inhalt,Lieferant,Preis,Barcode,Kommentar FROM barcodes';
SQLQuery1.Open;
//schreiben der Daten aus der Datenbak "barcodes" in die Listview
 while not SQLQuery1.Eof do
begin
 item:=mainFrm.ListView1.Items.Add;
 item.Caption:= SQLQuery1.FieldByName('ID').AsString;
 item.SubItems.Add(SQLQuery1.FieldByName('Produktname').AsString);
 item.SubItems.Add(SQLQuery1.FieldByName('Hersteller').AsString);
 item.SubItems.Add(SQLQuery1.FieldByName('Inhalt').AsString);
 item.SubItems.Add(SQLQuery1.FieldByName('Lieferant').AsString);
 item.SubItems.Add(SQLQuery1.FieldByName('Preis').AsString);
 item.SubItems.Add(SQLQuery1.FieldByName('Barcode').AsString);
 item.SubItems.Add(SQLQuery1.FieldByName('Kommentar').AsString);
 SQLQuery1.Next;
 SQLQuery1.Close;
end;
 //bei Programmstart auslesen der Datenbank "inhouse"
SQLQuery2.SQL.Clear;
SQLQuery2.Params.Clear;
SQLQuery2.SQL.Text:= 'SELECT IDIH,ProduktnameIH,HerstellerIH,istIH,sollIH,MHDIH,BarcodeIH,KommentarIH FROM inhouse';
SQLQuery2.Open;
//schreiben der Daten aus der Datenbank "inhouse" in die Listview
while not SQLQuery2.Eof do
 item2:=mainFrm.ListView2.Items.Add;
 item2.Caption:= SQLQuery2.FieldByName('IDIH').AsString;
 item2.SubItems.Add(SQLQuery2.FieldByName('ProduktnameIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('HerstellerIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('istIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('sollIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('MHDIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('BarcodeIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('KommentarIH').AsString);
 SQLQuery2.Next;
 SQLQuery2.Close;

Ich bin noch ziemlicher Anfänger und bin daher für jeden konstruktiven Tipp dankbar. Ich vermute den Fehler in der Art wie ich den Query angehe.

Vielen Dank.
LG Vienesko:)

[HolgerX]

Hmm..

Zitat:

Zitat von Vienesko (Beitrag 1379405)

Delphi-Quellcode:

//schreiben der Daten aus der Datenbank "inhouse" in die Listview
while not SQLQuery2.Eof do
 item2:=mainFrm.ListView2.Items.Add;
 item2.Caption:= SQLQuery2.FieldByName('IDIH').AsString;
 item2.SubItems.Add(SQLQuery2.FieldByName('ProduktnameIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('HerstellerIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('istIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('sollIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('MHDIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('BarcodeIH').AsString);
 item2.SubItems.Add(SQLQuery2.FieldByName('KommentarIH').AsString);
 SQLQuery2.Next;
 SQLQuery2.Close;

Fehlt da nach

Delphi-Quellcode:

while not SQLQuery2.Eof do

nicht ein 'begin..end'

[TigerLilly]

Ja, in der 2ten Schleife fehlt das begin/end + das SQLQuery.Close muss aus der Schleife raus:

while not SQLQuery1.Eof do
begin
item:=mainFrm.ListView1.Items.Add;
item.Caption:= SQLQuery1.FieldByName('ID').AsString;
item.SubItems.Add(SQLQuery1.FieldByName('Produktna me').AsString);
...
SQLQuery1.Next;
end;
SQLQuery1.Close;

[DeddyH]

Außerdem würde ich mir eine Hilfsroutine schreiben (nennen wir sie DisplayData), der man ein TDataset und eine TListView-Instanz übergibt. Innerhalb dieser Routine werden dann zunächst alle Spalten und Zeilen der ListView gelöscht. Dann liest man die Feldnamen des Datasets aus und erzeugt daraus die Spalten neu. Anschließend geht man das Dataset durch und erzeugt wie gehabt je Datensatz eine neue Zeile und befüllt sie. Dadurch ist man flexibler und hat diese ganze Logik an zentraler Stelle.

[p80286]

Und es wäre sinnvoll, vor dem Lesen der Daten die Listviews zu leeren.

Gruß
K-H

[TigerLilly]

:-) Es wäre sinnvoll, den Zugriff auf die Daten (=SQL) vom UI (=ListView) zu trennen.

[DeddyH]

Das ist immer sinnvoll. Die Frage ist nur, wie weit man (gerade als Anfänger) dabei gehen will. Wenn ich seit 3 Wochen programmiere, werde ich mich durch Begriffe wie Dependency Injection eher abgeschreckt fühlen.

[TigerLilly]

Zitat:

Zitat von DeddyH (Beitrag 1379420)

Das ist immer sinnvoll. Die Frage ist nur, wie weit man (gerade als Anfänger) dabei gehen will. Wenn ich seit 3 Wochen programmiere, werde ich mich durch Begriffe wie Dependency Injection eher abgeschreckt fühlen.

Das ist eine Sorge, die eigentlich nur Old School Programmierer haben. Wer neu beginnt, sollte solche Basics quasi schon mit der Muttermilch aufnehmen.

[Vienesko]

Erstmal vielen Dank für die vielen und vor allem hilfreichen Antworten.
Natürlich war es das vergessene "begin...end" und der Query.close innerhalb der Schleife.

Ich weiß nicht, warum mir das selbst nicht aufgefallen ist. Aber irgendwann ist man wahrscheinlich einfach blind dafür...:roll:

Das Andere müsst ihr mir aber erklären.

Ist mir der Hilfsroute gemeint, sich einemal eine Procedure zu schreiben, in der das abläuft und diese dann zu gegebener Zeit aufzurufen?

Und warum macht es sinn, die ListView zu leeren?
Warum Listview/SQL trennen?

Ich möchte ja was lernen und mich verbessern:)

Danke!

[haentschman]

Moin...:P

Zitat:

Ich möchte ja was lernen und mich verbessern

Dann mache ich mal den Erklärbär...:zwinker:

Wie weit du dich darauf einläßt und die Tipps umsetzt, ist dir überlassen. Als Anfänger hab ich mich auch nicht darum gekümmert...:oops: Aber auch als Anfänger sollte man es schon wenigstens gehört haben. Learning by doing ohne Hilfe ist nicht schlecht aber sehr zeitaufwendig. Besser ist, die erhaltenen Tipps selbst auszuprobieren und daraus zu lernen. Ich wünschte, daß hätte ich damals auch gehabt... :cry:

Dafür ist das Forum da...:thumb:

Der Reihenfolge nach:

1:
Progammierprinzipien: (die Wichtigsten)
DRY: https://de.wikipedia.org/wiki/Don%E2...epeat_yourself
* Dopplung von Code durch auslagern in Methoden vermeiden
* Bestehenden Code verwenden und danach suchen
KISS: https://de.wikipedia.org/wiki/KISS-Prinzip
* Wenn es mehrere Erklärungen für einen bestimmten Sachverhalt gibt, dann ist diejenige Erklärung zu bevorzugen, die am einfachsten ist, also mit den wenigsten Annahmen und Variablen auskommt.

Allgemein:
CamelCase: https://de.wikipedia.org/wiki/Binnenmajuskel
vernünftige Namen: Auch wenn es am Anfang lästig ist, man hat ja andere Probleme, ist es besser das man sich gleich daran gewöhnt. In 2 Monaten weist du nicht mehr was ListView1 ist. :zwinker:
Denglisch vermeiden: Auch wenn wir Deutsch sind... in der Programmierei ist Englisch die bevorzugte Sprache. Damit hat man auch die Probleme mit Umlauten vom Tisch. Wenn man dann in einem Team arbeitet muß man sich nicht umgewöhnen. 8-)
Styleguide: https://www.delphi-treff.de/object-pascal/styleguide/
WITH vermeiden: :warn: Fast vergessen. Mit WITH nimmst du dir alle Möglichkeiten den Code, bzw. die Variablen, zu debuggen. Erst Recht als Anfänger will man doch wissen was in der Komponente (Property) los ist... :zwinker:

2:
Werkzeuge allgemein:
Programmieren geht mit der Benutzung der zur Verfügung stehenden Werkzeuge los. Der CnPack ist einer davon. Mit den bunten Strichen im Quelltext wäre dir das:

Zitat:

Natürlich war es das vergessene "begin...end" und der Query.close innerhalb der Schleife.

selbst sofort aufgefallen.

Codeformatter:
Das Wichtigste ist ein gut formatierter Code. (kommt auch im Forum nicht schlecht...8-)) Mit einem Tastendruck (CnPack) ist alles "toll" ausgerichtet...:thumb:

Was ist besser?
das

Delphi-Quellcode:

while not SQLQuery1.Eof do
begin
item:=mainFrm.ListView1.Items.Add;
item.Caption:= SQLQuery1.FieldByName('ID').AsString;
item.SubItems.Add(SQLQuery1.FieldByName('Produktna me').AsString);
...
SQLQuery1.Next;
end;
SQLQuery1.Close;

oder das?

Delphi-Quellcode:

while not SQLQuery1.Eof do
begin
  Item := mainFrm.ListView1.Items.Add;
  Item.Caption := SQLQuery1.FieldByName('ID').AsString;
  Item.SubItems.Add(SQLQuery1.FieldByName('Produktname').AsString);
...
  SQLQuery1.Next;
end;
SQLQuery1.Close;

3.

Zitat:

Wer neu beginnt, sollte solche Basics quasi schon mit der Muttermilch aufnehmen.

...ein wahres Wort. 8-)

4.

Zitat:

Es wäre sinnvoll, den Zugriff auf die Daten (=SQL) vom UI (=ListView) zu trennen.

Trennung der Daten von der GUI ist das A und O.

allgemeiner Programmaufbau (Schicht Model):
https://de.wikipedia.org/wiki/Model_View_Controller
...ist für den Anfang zu kompliziert. Aber das ist das was damit gemeint wurde.

Für den Anfang kannst du dich an folgende Tipps halten:
* GUI<->Logik<->Datenbank Für jeden Part gibt es eine Unit oder DataModule.
* Definition der Datenablage...in der Regel die Unit mit der Logik. Die GUI holt sich direkt, oder über Events, die Daten dort ab. Das hat den Vorteil das du die GUI austauschen/verändern kannst ohne die Datenstruktur anzufassen.
* visuelle Controls niemals als Datenablage benutzen. Die Daten immer in der Logik vorhalten (Variable, DataSet etc.).
* SQL gehören nicht auf die Form oder in die auf die Form gepappte Query, sondern in eine seperate Unit oder Datenmodul. (erleichert den Austausch des DBMS)
* strikte Trennung Ablage der Prozeduren... alles was mit der GUI zu tun hat gehört in die Form, Berechnungen etc. in die Logik.

Zitat:

Außerdem würde ich mir eine Hilfsroutine schreiben (nennen wir sie DisplayData), der man ein TDataset und eine TListView-Instanz übergibt.

...hier scheiden sich die Geister. 8-) Wenn du eine allgemeine Prozedur machen willst, dann gehört diese in die Logik. Wenn du die procedure in der GUI mehrfach verwenden willst (DRY), kann die procedure auch in der Form plaziert sein. (weil: die procedure nur diese eine Form kennt)

Zitat:

in der das abläuft und diese dann zu gegebener Zeit aufzurufen?

...so ist es. :wink:

5.

Zitat:

Und es wäre sinnvoll, vor dem Lesen der Daten die Listviews zu leeren.

Wenn du die procedure mehrfach benutzt, solltest du am Beginn die Listview leeren, damit du nicht die Einträge aneinanderhängst. :wink:

6.
Datenbank:

Delphi-Quellcode:

item.Caption:= SQLQuery1.FieldByName('ID').AsString; // sollte in der Datenbank ein Integer und Primary Key sein!
...
item2.Caption:= SQLQuery2.FieldByName('IDIH').AsString; // sollte in der Datenbank ein Integer und Primary Key sein!
// Das ID Feld sollte in jeder Tabelle den gleichen Namen haben... :-) Verwechslungsgefahr...

Auch für die Datenbank gilt: "Denglisch vermeiden" und Präfixe für Felder- und Tabellennamen wegen der reservierten Worte der Datenbank. (F_xxx, T_xxx ...oder so )

7.
Verbesserungen:

Delphi-Quellcode:

/bei Programmstart auslesen der Datenbank "barcodes"
// verfünftige Namen

// wenn die Colums im OI definiert wurden. Mit lvBarcodes.Clear müssen auch die Colums definiert werden. Das ist das was DeddyH mit allgemein gemeint hatte.
lvBarcodes.Items.Clear; 
//QueryBarcodes.SQL.Clear; // nicht notwendig...passiert mit Zuweisung von "SQL.Text" automatisch
//QueryBarcodes.Params.Clear; // nicht notwendig...passiert mit Zuweisung von "SQL.Text" automatisch
QueryBarcodes.SQL.Text := 'SELECT ID,Produktname,Hersteller,Inhalt,Lieferant,Preis,Barcode,Kommentar FROM barcodes'; //Leerzeichen
QueryBarcodes.Open;
//schreiben der Daten aus der Datenbak "barcodes" in die Listview
while not QueryBarcodes.Eof do
begin
  Item := mainFrm.lvBarcodes.Items.Add; // Name
  Item.Caption := QueryBarcodes.FieldByName('ID').AsString;
  Item.SubItems.Add(QueryBarcodes.FieldByName('Produktname').AsString);
  Item.SubItems.Add(QueryBarcodes.FieldByName('Hersteller').AsString);
  Item.SubItems.Add(QueryBarcodes.FieldByName('Inhalt').AsString);
  Item.SubItems.Add(QueryBarcodes.FieldByName('Lieferant').AsString);
  Item.SubItems.Add(QueryBarcodes.FieldByName('Preis').AsString);
  Item.SubItems.Add(QueryBarcodes.FieldByName('Barcode').AsString);
  Item.SubItems.Add(QueryBarcodes.FieldByName('Kommentar').AsString);
  QueryBarcodes.Next;
end;
// außerhalb der Schleife. Imho ist Close nicht notwendig. Mit Zuweisung von "SQL.Text" und dem Open wird Close automatisch augeführt.
QueryBarcodes.Close;

Frage:
Ohne dir auf die Füße treten zu wollen...Wie kommt man als Anfänger an eine XE7 Enterprise? :gruebel:

Dann viel Spaß...

[nahpets]

Die Routine würd' ich noch ein bisserl allgemeiner machen:

Delphi-Quellcode:

var
  i : Integer;
  Item : TListItem;
begin
  lvBarcodes.Items.Clear;
  QueryBarcodes.SQL.Text := 'SELECT ID, Produktname, Hersteller, Inhalt, Lieferant, Preis, Barcode, Kommentar FROM barcodes';
  QueryBarcodes.Open;
  // schreiben der Daten aus der Datenbank "barcodes" in die Listview
  while not QueryBarcodes.Eof do
  begin
    Item := lvBarcodes.Items.Add; // Name
    // Der Wert der ersten Ergebnisspalte kommt nach Caption,
    // die übrigen Spalten werden in der Reihenfolge, 
    // in der sie im SQL stehen, übernommen.
    // Damit werden wir bei der Datenübernahme unabhängig vom
    // Inhalt der Datenmenge.
    Item.Caption := QueryBarcodes.Fields[0].AsString;
    for i := 1 to QueryBarcodes.Fields.Count - 1 do begin
      Item.SubItems.Add(QueryBarcodes.Fields[i].AsString);
    end;
    QueryBarcodes.Next;
  end;
  // außerhalb der Schleife. Imho ist Close nicht notwendig. Mit Zuweisung von "SQL.Text" und dem Open wird Close automatisch augeführt.
// Aber eine Datenmenge dann, wenn man sie nicht mehr benötigt, zu schließen, ist auch nicht unbedingt verkehrt.
  QueryBarcodes.Close;
end;

Oder noch allgemeiner:

Delphi-Quellcode:

procedure DataSetToListView(ds : TDataSet; lv : TListView);
var
  i : Integer;
  iCount : Integer;
  isActive : Boolean;
  Item : TListItem;
begin
  lv.Items.Clear;
  // Ist die Datenmenge offen?
  // Wenn nein, öffnen wir sie, 
  // ansonsten gehen wird zum ersten Datensatz.
  isActive := ds.Active;
  if not isActive then ds.Open else ds.First; // Man könnte sich auch noch den aktuellen Satz merken.
  iCount := ds.Fields.Count - 1;
  while not ds.EoF do begin
    Item := lv.Items.Add;
    Item.Caption := ds.Fields[0].AsString;
    for i := 1 to iCount do Item.SubItems.Add(ds.Fields[i].AsString);
    ds.Next;
  end;
  // Haben wir die Datenmenge selbst geöffnet, schließen wir sie auch wieder.
  if not isActive then ds.Close else ds.First; // oder zum ggfls. gemerkten Satz zurückgehen.
end;

Aufruf:

Delphi-Quellcode:

  QueryBarcodes.SQL.Text := 'SELECT ID, Produktname, Hersteller, Inhalt, Lieferant, Preis, Barcode, Kommentar FROM barcodes';
  DataSetToListView(QueryBarcodes,lvBarcodes);
  // Weitere Datenmengen, wenn Bedarf besteht:
  QueryIrgendwas.SQL.Text := 'select Name, Strasse, Ort form irgendeinertabelle';
  DataSetToListView(QueryIrgendwas,lvIrgendwas);
  ...

[haentschman]

Moin...:P

@nahpets:

Zitat:

Die Routine würd' ich noch ein bisserl allgemeiner machen

Ich bin kein Freund der absoluten Abstraktion. Ein wenig ist ja gut... :zwinker:

In deinem Beispiel:

Delphi-Quellcode:

procedure DataSetToListView(ds : TDataSet; lv : TListView);
var
  i : Integer;
  iCount : Integer;
  isActive : Boolean;
  Item : TListItem;
begin
  lv.Items.Clear;
  // Ist die Datenmenge offen?
  // Wenn nein, öffnen wir sie,
  // ansonsten gehen wird zum ersten Datensatz.
  isActive := ds.Active;
  if not isActive then ds.Open else ds.First; // Man könnte sich auch noch den aktuellen Satz merken.
  iCount := ds.Fields.Count - 1;
  while not ds.EoF do begin
    Item := lv.Items.Add;
    Item.Caption := ds.Fields[0].AsString;
    for i := 1 to iCount do Item.SubItems.Add(ds.Fields[i].AsString);
    ds.Next;
  end;
  // Haben wir die Datenmenge selbst geöffnet, schließen wir sie auch wieder.
  if not isActive then ds.Close else ds.First; // oder zum ggfls. gemerkten Satz zurückgehen.
end;

...hast du etwas nicht berücksichtigt:
1. Spaltennamen. Da die Klartextnamen der Spalten im DataSet nicht vorhanden sind, mußt du die anders "lagern"
2. Die Reihenfolge der Spalten ist von der Reihenfolge der Spalten in der DB abhängig. Für mich ein NoGo.

Letztendlich kann man diese Probleme auch lösen. Das erzeugt imho mehr Aufwand als der klassische Weg und verstößt damit gegen das KISS Prinzip. :zwinker:

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1379550)

2. Die Reihenfolge der Spalten ist von der Reihenfolge der Spalten in der DB abhängig. Für mich ein NoGo.

Vertan?

Die Reihenfolge wir durch das Select-Statement bestimmt. Und hier kannst Du auch gleich die Feldnamen "sprechender" gestalten. z.b.

SQL-Code:

"select ID, Firstname as Vorname, Familyname as Familienname ..."

Was bei mehrsprachigen Anwendungen allerdings ein NoGo ist.

Gruß
K-H

[nahpets]

@haentschman
Naja, war halt nur ein Beispiel für: Wenn es sehr unabhängig sein soll.

Spaltennamen stehen im DataSet schon drin:

Delphi-Quellcode:

DataSet.Fields[FeldNr].FieldName

Wenn ich die brauche, komm ich da auch problemlos dran.

Und die Spaltennamen sind nicht von der Reihenfolge in der DB abhängig, sondern von der Reihenfolge im SQL. Hier kann ich sie also durchaus ganz klar, so wie in Deinem Beispiel, bestimmen. Eine "Zufallsreihenfolge" erhalte ich nur bei einem

Delphi-Quellcode:

select * from Tabelle

.

Für mich ist es ein NoGo, wenn in der Anzeige die Spaltenreihenfolge fest vorgegeben ist. Die soll der Anwender, wenn möglich, selbst bestimmen können. Seine persönliche Konfiguration wird beim Programmende gespeichert und beim Neustart wieder hergestellt.

Zugegeben: Bisher bin ich noch nicht auf die Idee gekommen, Daten aus 'ner Datenbank in 'nem Listview darzustellen, da nehme ich lieber ein Grid, aber das ist sicherlich eine persönliche Ansicht. Je nach Aufgabe mag es sehr unterschiedliche, sinnvolle und praktikable Lösungsmöglichkeiten für die Darstellung der Daten geben.

@p80286
Da bei mir für gewöhnlich SQL-Statements nicht fest verdrahtet in der Anwendung stehen, sondern in 'ner Datenbanktabelle (um darüber auch eine Datenbankunabhängigkeit einfacher realisieren zu können), habe ich mit Deinem Vorschlag sogar die recht einfache Möglichkeit, sprachunabhängig zu sein, indem ich die Spaltennamen eben so, wie Du es vorschlägst, an die Anzeigesprache anzupassen.

Was dann allerdings nicht geht, ist: Im Programm die Spalten über FieldByName anzusprechen, das geht dann gewaltig schief ;-)

Aber da Anzeige und sonstige Datenzugriffe getrennt sind, ist das kein unlösbares Problem.

[haentschman]

Hallöle...:P

Zitat:

Die Reihenfolge wir durch das Select-Statement bestimmt.

...aber ja doch. 8-) Ein Versprecher muß sein. :wink:
Trotzdem muß ich nicht beim "Design" des SQL darübernachdenken in welcher Reihenfolge die Daten angezeigt werden. Das hat das Statement nicht zu interessieren. :roll:
Und wie machst du das wenn nicht ALLE Felder angezeigt werden sollen...aber trotzdem mit geladen werden sollen? Hilfsfelder etc.? :gruebel:

Zitat:

Familyname as Familienname

Zitat:

Was bei mehrsprachigen Anwendungen allerdings ein NoGo ist.

Ich stehe nach wie vor dazu, das das SQL nicht die Visualisierung wiederspiegeln soll. :thumb: Wenn ein Datenbankfuzzi nur die SQL optimiert und von deiner Visualisierung nichts weiß...gute Nacht Marie. :stupid:

[nahpets]

Für die Anzeige lade ich nur die Daten, die für die Anzeige benötigt werden.

Ich käme nie auf die Idee Daten zu laden und davon dann nur eine Teilmenge anzuzeigen.

Die anzuzeigenden Daten haben bei mir nichts mit den sonstigen Daten, die im Programmablauf benötigt werden, zu tuen.

Ein Select * gibt es für mich bei Anzeigedaten nicht, da ich ja dann immer von der Tabellenstruktur in der Datenbank abhängig bin. Bei 'ner Umstrukturierung kann ich mit 'nem FieldByName und Select * immer scheitern.

Wenn auf der Datenbank was geändert wird, kann ich im SQL immer mit Spaltenname as SoSollErBeiMirHeißen reagieren, mit dem * hab ich diese Möglichkeit nicht.

Gehe mal davon aus, dass wir sehr unterschiedliche Ansatzweisen haben, beide haben ihre Berechtigung, die "ultimativ beste Lösung" gibt es meiner Meinung nach nicht. Sollten wir die hier finden wollen, weichen wir arg vom Thema ab. Daher: Lassen wir es gut sein. Es gibt mehrere Vorschläge, die die Ursprungsfrage beantworten. Welcher davon im konkreten Fall die sinnvollere und / oder bessere ist, möge der Fragesteller für sich entscheiden.

[haentschman]

Zitat:

möge der Fragesteller für sich entscheiden.

...so ist es. :P

[himitsu]

Weitere Alternative: Die Daten via Live-Binding vom DataSet automatisch in die Komponente schieben lassen.

Oder statt dem ListView direkt eine datensensitive Komponente (DBGrid) verwenden.

Zitat:

Zitat von haentschman (Beitrag 1379518)

Frage:
Ohne dir auf die Füße treten zu wollen...Wie kommt man als Anfänger an eine XE7 Enterprise? :gruebel:

Trial
SSL
"kostenlos" gedownloaded
oder so

[Vienesko]

Wow:shock:
Bin gerade etwas erschlagen von den ganzen Antworten.
Danke an alle und besonders an haentschman für seine ausführliche Erklärung:)

Ich werde mich mit den Punkten nach und nach befassen. Ich finde es super dass du - einem Anfänger wie mir - so viel Zeit widmest und das niederschreibst.
Ich versuche mir das Programmieren tatsächlich mit "learning by doing" beizubringen. Deshalb ist das bei mir ja auch ein wenig Kraut und Rüben. Teilweise ist der Code, den ich gepostet habe, auch ein wenig Trial and Error.

Momentan habe ich einfach eine Vorstellung von dem, was mein Programm alles einmal können soll. Es ist nur für mich selbst und soll nie veröffentlicht werden. Es gibt ein Grundgerüst und das möchte ich nun nach und nach mit Funktionen füllen. Momentan ist die Datenbank dran aber es soll noch viel mehr folgen.

Natrülich sagt mir vieles von dem, was ihr hier geschrieben habt, noch nicht viel. Wahrscheinlich fehlen mir noch viele Grundlagen aber ich glaube ich lerne mehr (und habe mehr Spaß daran) direkt loszulegen und aus meinen Fehlern zu lernen anstatt trocken nur Bücher zu wälzen. Es ist einfach ein super Gefühl wenn man einen Stunde an etwas gesessen hat und es schlussendlich so funktioniert, wie man das wollte:-D

Ich werde als nächstes auf jeden Fall den einen oder anderen Tipp direkt umsetzen. z.B. meine Komponenten einheitlich und logisch zu benennen und Struktur in meinen Code zu bringen. Außerdem einige Funktionen "auszulagern" - also zu lernen wie das geht.

Zitat:

Zitat von haentschman (Beitrag 1379518)

Ohne dir auf die Füße treten zu wollen...Wie kommt man als Anfänger an eine XE7 Enterprise? :gruebel:

Ach alles gut. Über die Firma wo ich arbeite habe ich uneingeschränkten Zugriff auf so eine Version. Privat habe ich so eine nicht sondern (leider) nur eine Delphi 7 aus Schultagen. Naja...vielleicht ändert sich das auch noch irgendwann:wink:

[himitsu]

https://www.embarcadero.com/free-tools

[haentschman]

Zitat:

Ich werde mich mit den Punkten nach und nach befassen.

:thumb: löblich... Wenn du Fragen hast, dann mache bitte jeweils einen neuen Thread auf. :wink:

[p80286]

@Haentschman
In den meisten meiner Anwendungen ist der Delphi-Teil nur ein "doofer Datenschaufler". Inhalt und manchmal Form wir über das Select-Statement gesteuert, da hab ich automatisch eine etwas andere Sicht der Dinge.


Gruß
K-H