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.