DBLookupComboBox ohne Lookup-Tabelle

[wolfis]

Hallo, ich suche nach einer Möglichkeit, eine DBLookupComboBox o.ä. ohne Datenbank-Lookup-Tabelle zu verwenden.
Das heißt, die Lookup-Tabelle hat nur 6 Einträge und die will ich direkt ins Programm eingeben.
Im Datenbankfeld steht nur ein Integerwert (1-6), bei der Eingabe sollen aber 6 Zeilen mit je ca. 40 Zeichen angezeigt werden.
Wenn ich eine DBComboBox nehme und bei Items z.B. '1; Erster Eintrag' eingebe, will er den ganzen String in das Datenbankfeld füllen.
Das Problem ist eigentlich sehr einfach, ich hab aber noch keine Lösung gefunden.
Wenn ich die Lookup-Tabelle in der Datenbank anlege, geht es natürlich. Dies ist aber Overkill bei nur 6 Einträgen.

Grüße aus Bayern
Wolfgang

[waldforest]

Hallo,

ich denk mit den Items und anschließendem
dbcbb1.ItemIndex dürfte es funktionieren.

[himitsu]

Es muß ja nur DataSet dran, aber wo das DataSet die Daten herbekommt, ist der ComboBox vollkommen egal.



TempTable erstellen, befüllen und laden.

Oder als Select zusammensetzen.

SQL-Code:

SELECT 1, 'abc'
UNION
SELECT 2, 'def'
UNION
SELECT 3, 'xyz'

Und manche Datenbanken bieten Funktionen, um eine "Serie" von Werten zu erstellen.

SQL-Code:

SELECT CreateSeries(1, 6)  -- Anfang=1 Anzahl=6 Schrittweite=1(default)

Oder du verwendest ein Memory-DataSet (im Delphi gibt es das TClientDataSet und oftmals bringen fremde DBZugriffskomponenten ein eigenes MemDataSet mit)
Das kann man dann z.B. via Code im Delphi füllen.

Oder du nimmst eben keine Item-seitig db-gebundene DBComboBox, denn da bist du nicht gezwungen ein LookUp-DataSet anzuhängen. :zwinker:

[wolfis]

Hallo wf,

wenn ich die DBComboBox mit der Datenbank verbinde, schreibt er immer die ganze Zeile von Items in die Datenbank.
Ich brauche aber eine Methode, damit nur der index (1-6) in die Datenbank geschrieben wird

[Sir Rufo]

Ein TClientDataSet nehmen und an die LookupComboBox hängen

[Furtbichler]

Es ist keine Schande (im Gegenteil) Lookuptabellen mit nur sehr wenigen Einträgen in der DB zu haben. Deine Spalte hat z.B. die Werte 1,2,3,4,5,6. Dies repräsentiert Farben (rot,blau,grün,gelb,grau,schwarz).

Ohne eine derartige Lookuptabelle (und natürlich einem FK-Constraint) weiß keine Sau, was 1,2,3,4,5,6 bedeutet. Mit Lookuptabelle schon. Deine Daten sind somit nicht nur dokumentiert, es ist mit einer Lookuptabelle auch möglich einen vollständigen Report zu generieren, ohne deine Anwendung zu verwenden.

Eine Lookuptabelle *nicht* zu verwenden, ist ein Anti-Pattern.

[jobo]

Furtbichler hat meine vollste Zustimmung!
Allein die Zeit, die Du bis jetzt vergeudet hast, eine none-standard Lösung zu finden, ist schon rausgeworfenes Geld.
Ganz zu schweigen von den Effekten, die sich dann irgendwann ergeben.
Z.b. an dem Tag, wo jemand rausfindet, dass man da viel mehr Werte eintragen kann, als Deine Anwendung erlaubt, geht der Ärger los. Vielleicht ist grad niemand da, der Deine Anwendung umprogrammieren kann, es ist aber dringend. Oder oder oder, das Leben ist kreativer als ich..

Diese ganzen Sparideen ergeben meist nur eins, ein Codemoloch im Client.

Und was war noch mal der Overkill? Ein vier Zeilen langes Create Table für die Lookupwerte?
Overkill (für den Anwender) würde ich sagen beginnt bei > 50 Einträgen im Lookup.
Darunter ist alles bestens, darüber sollte es eher eine filterbare LookupCombobox sein.

[Union]

Von DevExpress gibt es dafür die TcxDBExtLookupComboBox. Das Ding hat ein EditValue, das beliebig belegt werden kann und an das Popup kann ein Grid-Repository gehängt werden. Ich verwende das z.b. bei Selektionen, wo ich intern eine ID brauche, die aber nur im Erfassungdsdialog existiert. So spart man sich das Generieren eine extra Datasets.

[Furtbichler]

Ich habe früher ein TdxMemData dafür verwendet (also ein In-Memory Dataset, so wie das himitsu und Sir Rufo bereits erwähnt haben. Ich wollte hier nur eindringlich davor warnen, qualitative Merkmale einer Datenbank außerhalb dieser zu beschreiben, wie dies hier offensichtlich erwünscht und wohl auch von einigen Mitstreitern praktiziert wird.

[Perlsau]

Ich gehe sogar so weit, daß ich in zahlreichen DB-Anwendungen eine Tabelle Geschlecht (3 Einträge: unbekannt, männlich, weiblich) mitführe, die z.B. auch die jeweilige Anrede enthält, manchmal auch eine Titel-Tabelle. Oder für meine Video-Verwaltung eine Tabelle Formate (wenige Einträge) und sogar eine Tabelle Dateisysteme (bislang zwei Einträge: Fat32 und NTFS). Ich verstehe das auch nicht, wieso man sowas unbedingt in der Anwendung unterbringen sollte. Das macht doch den Kohl nicht fett, hier zusätzliche Tabellen anzulegen, erleichtert Programm-Entwickung und -Pflege und Neuentwicklung. In den meisten DB-Anwendungen habe ich sogar die Benutzerverwaltung nebst Benutzereinstellungen in der Datenbank, denn wozu eine Ini-Datei oder Registry-Einträge, wenn ich sowieso eine Datenbank einsetze.

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1250092)

In den meisten DB-Anwendungen habe ich sogar die Benutzerverwaltung nebst Benutzereinstellungen in der Datenbank, denn wozu eine Ini-Datei oder Registry-Einträge, wenn ich sowieso eine Datenbank einsetze.

Na ja. Die Adresse des DB-Servers in der DB zu speichern ist vielleicht nicht ganz so zielführend. :stupid:

Aber sonst: :thumb:

Leider gibt es ein kleines Problem dabei, das gelöst werden muss. Angenommen, wir haben eine Eigenschaft 'Geschmack' mit der entsprechenden Tabelle 'Süß', 'Sauer', 'Bitter', 'Salzig'. (Werte = 1,2,3,4)

Nun muß die Software bie einem süßen Gericht Schlagsahne anbieten. Also muss die Anwendung wissen, das 'Süß=1' ist. Das ist natürlich kein Riesenproblem, aber diese Tastsache ist an zwei Stellen hinterlegt (in der DB und in der Anwendung). Ändert man z.B. die Reihenfolge in der DB (bei einer Neuinstallation z.B.), funktioniert die ganze Anwendung nicht mehr.

Wie gesagt: Ein grundsätzliches Problem, das normalerweise nicht zum Tragen kommt (außer, ein Schwachmat editiert die Lookuptabelle), aber hier würde ich trotzdem noch Prüfungen einbauen und z.B. sicherstellen (per Trigger z.B.) das die Tabelle nicht änderbar ist. Alternativ kann eine solche Tabelle auch ein 'Tag' Element enthalten, das die eigentliche Semantik abbildet. D.h. nicht die ID der Lookuptabelle definiert die Eigenschaft, sondern das Tag-Element. Dieses Element kann nicht verändert werden, aber z.B. der Text, dann ist die Tabelle übersetzbar. Natürlich ist man wieder am Arm, wenn man 'Süß' mit 'Salt' übersetzt...

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1250100)

Zitat:

Zitat von Perlsau (Beitrag 1250092)

In den meisten DB-Anwendungen habe ich sogar die Benutzerverwaltung nebst Benutzereinstellungen in der Datenbank, denn wozu eine Ini-Datei oder Registry-Einträge, wenn ich sowieso eine Datenbank einsetze.

Na ja. Die Adresse des DB-Servers in der DB zu speichern ist vielleicht nicht ganz so zielführend. :stupid:

Naja, mein lieber Furtbichler, ein so großer Schwachmat bin ich dann doch wieder nicht. Aber hier benötige ich auch weder Registryeintrag noch Inidatei, weil ich das gewöhnlich über Startparameter löse. Dort steht dann z.B. nur "0" drin, was bedeutet, daß es sich um eine Embedded Firebird DB handelt, die im Anwendungsordner liegt, oder auch "0 E:\Datenbanken", wobei die DB im bezeichneten Ordner liegt, oder auch "1 E:\Datenbanken", was lokaler FB-Server mit DB im angegebenen Verzeichnis bedeutet usw.

Zitat:

Zitat von Furtbichler (Beitrag 1250100)

Aber sonst: :thumb:

Leider gibt es ein kleines Problem dabei, das gelöst werden muss. Angenommen, wir haben eine Eigenschaft 'Geschmack' mit der entsprechenden Tabelle 'Süß', 'Sauer', 'Bitter', 'Salzig'. (Werte = 1,2,3,4)

Nun muß die Software bie einem süßen Gericht Schlagsahne anbieten. Also muss die Anwendung wissen, das 'Süß=1' ist. Das ist natürlich kein Riesenproblem, aber diese Tastsache ist an zwei Stellen hinterlegt (in der DB und in der Anwendung). Ändert man z.B. die Reihenfolge in der DB (bei einer Neuinstallation z.B.), funktioniert die ganze Anwendung nicht mehr.

Bei einer Neuinstallation sollten doch eigentlich alle vom Anwender eingegebene Daten aus der "alten" DB übernommen werden. Ist die alte DB nicht mehr verfügbar, spielt es keine Rolle, denn dann gibt es die Geschmacksrichtungen ja noch nicht. Oder diese Geschmacksrichtungen sind bereits fest vorgegeben (bzw. werden bei der Installation eingetragen), dann wird wohl auch die Reihenfolge eingehalten werden. Wenn ich z.B. Datenbank-Portierungen mache (entweder von zwei verschiedenen DBMS oder innerhalb desselben DBMS), werden immer zuerst die Sub-Tabellen übertragen, damit die Ids passen. Aber das hat doch mit meiner Vorgehensweise, benutzerdefinierte Einstellungen in der DB abzulegen, nichts zu tun, es sei denn, du betrachtest alles, was der Anwender in die DB einträgt, als benutzerdefinierte Einstellungen. Ich meinte damit lediglich das, was man gewöhnlich in den Optionen stehen hat nebst den sonstigen Values wie Fenstergrößen und -positionen, Spaltenbreiten usw.

Zitat:

Zitat von Furtbichler (Beitrag 1250100)

Wie gesagt: Ein grundsätzliches Problem, das normalerweise nicht zum Tragen kommt (außer, ein Schwachmat editiert die Lookuptabelle), aber hier würde ich trotzdem noch Prüfungen einbauen und z.B. sicherstellen (per Trigger z.B.) das die Tabelle nicht änderbar ist. Alternativ kann eine solche Tabelle auch ein 'Tag' Element enthalten, das die eigentliche Semantik abbildet. D.h. nicht die ID der Lookuptabelle definiert die Eigenschaft, sondern das Tag-Element. Dieses Element kann nicht verändert werden, aber z.B. der Text, dann ist die Tabelle übersetzbar. Natürlich ist man wieder am Arm, wenn man 'Süß' mit 'Salt' übersetzt...

Das führt uns jetzt aber doch wenig zu weit weg vom ursprünglichen Thema, oder nicht?

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1250101)

Naja, mein lieber Furtbichler, ein so großer Schwachmat bin ich dann doch wieder nicht.

Hast Du den Grinsemann am Ende meines 'Einwandes' gesehen? Ja. Korrekt interpretiert? Offensichtlich nicht.

Zitat:

Das führt uns jetzt aber doch wenig zu weit weg vom ursprünglichen Thema, oder nicht?

Ganz und gar nicht. Das ist das große Problem von Lookuptabellen bzw. der Problematik, Geschäftsregeln an mehr als einer Stelle zu hinterlegen. Wie löst Du denn dieses Problem? Woher weiß dein Programm, das Süss=1 ist? Steht das irgendwo? Ja, oder? Im Code *und* in der Datenbank.

[jobo]

Zitat:

Zitat von Furtbichler (Beitrag 1250100)

..
Leider gibt es ein kleines Problem dabei, ...

Ich versteh das Problem mit der doppelten Definition nicht so richtig.
Entweder ich arbeite mit irgendwelchen Nutzdaten, dann sind ID und Text (egal welche Sprache) erstmal wurscht.
Konkret, erfindet mein Kunde eine neue Produktgruppe und verwendet diese bei der Anlage neuer Artikel, kann das der DB, der Anwendung und mir egal sein.
Oder ich arbeite mit- nennen wir es Anwendungsdaten- deren Werte durch die Businesslogik verwendet werden. Hier hat der Benutzer nichts zu editieren, weil er bestenfalls nichts Neues schafft, eher aber bestehende Zusammenhänge zerstört. Als Entwickler muss man dafür sorgen, dass diese Daten (auch beim Erstellen oder migrieren einer Datenbank) konstant bleiben.
Konkret, hat mein Kunde die Gruppe Grillfleisch angelegt, muss er eine weitere Zuordnung dieser neuen Produktgruppe treffen, die entsprechend im System registrierte Regelwerke und Stammdaten für Lebensmittel/(frisch)Fleisch definiert.
In diesem Bereich der Anwendungsdaten ID oder Texte zu editieren ist selbst dann sinnlos, wenn alle Zusammenhänge bekannt sind / berücksichtigt werden, da für die neue Daten keine korrespondierenden Regeln im System vorliegen.

Was sehr praktisch ist bei dem ganzen Thema:
Lookup Daten per View bereitstellen. Damit habe ich einen extra Freiheitsgrad, den ich für unterschiedlichste Zwecke einsetzen kann.

[Furtbichler]

Zitat:

Zitat von jobo (Beitrag 1250109)

Ich versteh das Problem mit der doppelten Definition nicht so richtig.

Es ist ein Designproblem. Die Tatsache, das z.B. Grün=1 ist, ist -wie erwähnt- an zwei Stellen hinterlegt. Im Code hast Du z.B.
In der Datenbank

ID	Text
1	Grün

Und im Code

Delphi-Quellcode:

Const
  Gruen=1;
...
Case Farbe of
  Gruen : MalEsGelbAn();
  Rot : StampfEsEin();
...

Problem ist, wenn Du entweder die CONST-Deklaration oder aber den eintrag in der Lookuptabelle änderst (oder der Kunde).

ID	Text
1	Rot
2	Grün

Denn dann wählt der Anwender 'Grün' aus und die Anwendung macht jetzt etwas anderes.

Zitat:

Konkret, erfindet mein Kunde eine neue Produktgruppe und verwendet diese bei der Anlage neuer Artikel, kann das der DB, der Anwendung und mir egal sein.

Absolut korrekt. Derartige anonyme Daten sind von dieser Problematik nicht betroffen. Das Problem besteht bei Ausprägungen (also Daten), deren Bedeutung im Code eine Rolle spielt.

Zitat:

Oder ich arbeite mit- nennen wir es Anwendungsdaten- ... eher aber bestehende Zusammenhänge zerstört. Als Entwickler muss man dafür sorgen, dass diese Daten (auch beim Erstellen oder migrieren einer Datenbank) konstant bleiben...

Genau. Und darauf wollte ich hinaus.

Zitat:

In diesem Bereich der Anwendungsdaten ID oder Texte zu editieren ist selbst dann sinnlos

ID = ja. Text = nein. Text muss editierbar (oder besser: veränderbar) bleiben.

Zitat:

Was sehr praktisch ist bei dem ganzen Thema: Lookup Daten per View bereitstellen.

Das ist eine gute Idee, denn ich kann z.B. die Mehrsprachigkeit hinter der View verbergen.