Nochmal: Werte werden in der LookUpComboBox übersprungen, siehe E. Sausy & A.Kosch

[Hendrik]

Liebe Elke,
ich habe das gleiche Problem und bin dabei mir zu überlegen neue Komponenten zu kaufen. Es scheint eindeutig ein Problem der <br>
LookUpComboBoxen zu sein. Ich habe eine kleine Access97 DB aufgesetzt (Ausgaben), die 3 Tabellen beinhaltet: <br>
KLASSAs (Hauptkategorie, enthält nur ein Feld KLASSA)<br>
KLASSBs (Unterkategorie, enthält KLASSA und KLASSB)<br>
Artikel (Ausgaben, enthält KLASSA, KLASSB, Artikel, Datum, Menge, Preis)<br>
Für KLASSBs ist KLASSAs Datasource, IndexFieldNames sind KLASSA;KLASSB.<br>
Bei der Aufnahme von neuen Ausgaben funktioniert alles prima, KLASSA und KLASSB können in den jeweiligen LookupComboBoxen<br>
problemlos selektiert werden, in der Box für KLASSB erscheinen auch nur die Einträge von KLASSB die die entsprechenden KLASSA <br>
Werte haben. Soweit so gut.<br>
Laufe ich jetzt aber die Ausgaben - Tabelle durch (mit 'nem Navigator) werden nach dem Wechsel eines KLASSA - Wertes <br>
in der Box für KLASSB kein Wert angezeigt, obwohl die DB den richtigen Wert liefert:<br>
<pre>
procedure TF_AUSGABEN.DBNavigator2Click(Sender: TObject; Button: TNavigateBtn);
var KLASSB:string;
begin
KLASSB:=T_AUSGABEN.FieldByName('KLASSB').asstring;
ShowMessage(KLASSB);
// kommt richtig, folglich eine Frage der Anzeige
end;
</pre>

also auch lieber Herr Kosch, wozu Clone? wenn T_Ausgaben die korrekten KLASSB - Wert liefert,<br>
der aber in der Box nicht angezeigt wird?<br>
Hendrik

[Andreas Kosch]

Hallo,

wenn man für TLookUpComboBox eine <b>eigene</b> Datenmenge vorsieht, gibt es meines Wissens nach <b>keine</b> Probleme (ich habe jedenfalls noch keine selbst zu Gesicht bekommen). Ärger gibt es nur dann, wenn man von "außen" den Datensatzzeiger der Datenmenge ändert, die von TLookUpComboBox für die Anzeige verwendet wird

[Hendrik]

Also ich glaube jetzt fast, Sie haben irgendwie Recht Hr. Kosch.
Ich habe mir jetzt verschiedene DBLookUpComboBoxen als Trial-Version
runtergeladen, alle zeigen ein analoges (unmögliches) Verhalten.
Dabei sind, wie hier gezeigt, die Sachen richtig positioniert:
<pre>
procedure TF_AUSGABEN.DBNavigator2Click(Sender: TObject;Button: TNavigateBtn);
var KLASSB,KLASSB1:string;
begin
KLASSB:=DM_BUDGET.T_AUSGABEN.FieldByName('KLASSB') .asstring;
KLASSB1:=DM_BUDGET.T_KLASSBs.FieldbyName('KLASSB') .asstring;
ShowMessage('aus Ausgaben: ' + KLASSB + ' aus KLASSB: ' + KLASSB1);
// kommt richtig
end;
</pre>
Der Fehler (in der Anzeige?) tritt immer dann auf, wenn ein
Kategoriewechsel in KLASSA eintritt. Dann wird entweder nichts
angezeigt oder eine falsche Kategorie KLASSB. Die Ausgabenliste
wird mit 'select * from Ausgaben order by Datum,KLASSA,KLASSB,Artikel'
geöffnet.
Ich weiß nun echt nicht mehr weiter.
Übrigens lassen sich in der DBLookUpComboBox für KLASSB die Einträge
nicht per shortcut selectieren, was in der Box für KLASSA hervorragend
funktioniert.
Hendri

[Andreas Kosch]

Hallo,

spätestens dann, wenn auch andere Komponenten das gleiche (falsche) Verhalten zeigen, würde ich die Ursache in meinem Code suchen. Die folgende Checkliste sollte dabei hilfreich sein: <br>
1. Verwenden alle Tabellen einen geeigneten Primärschlüssel? <br>
2. Gibt es auch wirklich eine exakte 1:n-Beziehung, die über TLookupComboBox <b>eindeutig</b> dargestellt werden kann? <br>
3. Verwendet jede TLookupComboBox-Instanz eine eigene Datenmenge, die von keiner anderen Stelle aus direkt angesprochen wird?

P.S: Ich gehe davon aus, dass die verwendete Tabellenstruktur gegen die 2. Regel verstösst. Wer generell mit Primär- und Fremdschlüsseln in seinen Tabellen hantiert, kann niemals auf dieses Problem stossen.

[Hendrik]

@A. Kosch,
vielen Dank für die Hinweise Hr. Kosch, ich mußte tatsächlich feststellen, daß die referentielle Integrität in der DB nicht wirklich gesichert ist (war mal 'n Excel - Import). Nun bin ich erstmal dran das in Ordnung zu bringen (ca 30.000 Sätze). Dann werde ich weitersuchen.<br>
Hendri