Filter auf LOOKUP-Feld, alternative INNER JOIN und Editproblem

[waldforest]

Hallo,
ich nutze eine normierte Datenbank, in der z.B. in der Rechnungstabelle über die Kundennummer in einer Kundentabelle auf den Kundennamen verwiesen wird.

Zur Anzeige meinr Rechnungsdaten incl. Kundennamen in einm DBGRID habe ich zwei Varianten ausprobiert, keine ist optimal.

1.) Ich habe den Kundennamen über ein Lookup im Query ergänzt. Der Nachteil ist nun, wenn ich in der Rechnungsdatenbank nach bestimmten Kunden filtern will, dass dies auf dieses Lookupfeld nicht möglich ist.

2.) Ich habe den Kundennamen über einen INNER JOIN im Query integriert. Nun funktionier der Filter, aber ich kann den Datensatz nicht in den EDIT-Modus bringen, da dies über verbundene Tabellen nicht möglich ist.

Gibt es eine Möglichkeit, wie eine Filterung, aber auch eine weiter Bearbeitung des Datensatzes möglich ist, wie könnte diese aussehen ?

[haentschman]

Hallo...

Ohne deine Arbeit zu schmälern... Du bist auf den Klassiker aufgelaufen. Datensensitive Controls sind für "einfache" Sachen geeignet. Mit steigenden Anforderungen wird das immer schwieriger bzw. ist nur mit Workarounds zu Workarounds lösbar.
Ich kann dir nicht wirklich helfen, da es so ist wie du schon beschrieben hast. Ich kann dir nur empfehlen dich in absehbarer Zeit von den datensensitiven Controls zu verabschieden. Dabei mußt du dich um das Laden, Darstellen, Editieren und Speichern selbst kümmern. Für diese Mehrarbeit wirst du aber auch belohnt mit Controls welche bisher nicht nutzbar waren (keine DB Anbindung) um damit ein besseres Aussehen zu ermöglichen.

[Sir Rufo]

Wie willst du denn filtern?

Wenn du eine LIKE Suche über den Kundennamen möchtest, dann suche dir separat die passenden Kunden-IDs und filtere damit deine Sätze.

@haentschman

Das DBGrid hat mit dem Filtern nichts zu tun. Welches Control stellt sich denn da quer?

[haentschman]

Zitat:

Das DBGrid hat mit dem Filtern nichts zu tun.

Zitat:

...aber auch eine weiter Bearbeitung des Datensatzes möglich ist...

Er will aber auch editieren. Das ist mit der gejointen Datenmenge nicht drin. (2.)

[Sir Rufo]

Zitat von haentschman:

Zitat:

Das DBGrid hat mit dem Filtern nichts zu tun.

Zitat:

...aber auch eine weiter Bearbeitung des Datensatzes möglich ist...

Er will aber auch editieren. Das ist mit der gejointen Datenmenge nicht drin. (2.)

Der JOIN ist ja auch nicht nötig ...

[mkinzler]

Man kann die Abfrage aber editierbar machen, indem man Update/Delete/Insert-SQL Abfragen hinterlegt (bei Zeos im UpdateSQL-Objekt)

[Perlsau]

Würde sich da nicht das Erstellen eines Views anbieten?

[waldforest]

Hallo,
erst einmal vielen Dank für die Tipps, Hinweise zu datensensitiven Komponenten, Subabfrage etc. .

Ich habe den Tipp mit dem Zeos UpdateSQL einmal verfolgt (es klappt) und denke, dass dies, zumindest aktuell die schnellste Lösung ist.
Mal sehen, wann und wo ich an erneute Grenzen stoße.

Das Thema Views habe ich bisher noch nicht verfolgt, denke aber, dass dies eines meiner nächsten Entwicklungsschritte in meiner Hobbyprogrammierung sein werden.

[Perlsau]

Zitat von waldforest:

Das Thema Views habe ich bisher noch nicht verfolgt, denke aber, dass dies eines meiner nächsten Entwicklungsschritte in meiner Hobbyprogrammierung sein werden.

Ein View ist im Prinzip nichts anderes als ein spezielles Select-Ergebnis, das in der Datenbank vorgehalten wird. Es werden dabei keine weiteren Tabellen erzeugt. Ich verwende Views sehr häufig, z.B. als Report-Basis oder eben zum leichteren Selektieren, Filtern und Sortieren. Ein View kannst du quasi als Tabelle behandeln und daher via Query-Komponente genau so abrufen wie jede andere Tabelle.

Im IbExpert erstellt man ein View, indem man im DB-Baum einen Rechtsklick auf Views ausführt und Neues View wählt. Bevor ich dir jetzt alles haarklein erkläre, hilft dir vielleicht ein Beispiel, das ich in meiner Projektverwaltung einsetze und das mir alle relevanen Kundendaten in einer quasi virtuellen Tabelle präsentiert:

Code:

CREATE OR ALTER VIEW A_KUNDEN(
    KUNDE_INDEX,
    KUNDE_FIRMA,
    KUNDE_NACHNAME,
    KUNDE_VORNAME,
    KUNDE_STRASSE,
    KUNDE_HNR,
    KUNDE_PLZ,
    KUNDE_ORT,
    KUNDE_BANK,
    KUNDE_BLZ,
    KUNDE_PAN,
    KUNDE_BIC,
    KUNDE_KONTO,
    KUNDE_NAME_FULL,
    KUNDE_STRASSE_FULL,
    KUNDE_ORT_FULL,
    KUNDE_GESCHLECHT,
    KUNDE_ANREDE,
    KUNDE_LAND,
    KUNDE_EMAIL,
    KUNDE_HOMEPAGE,
    KUNDE_FESTNETZ,
    KUNDE_HANDY,
    KUNDE_MEMO,
    KUNDE_ZEIT,
    KUNDE_ZEIT_STRING,
    KUNDE_PROJEKTE,
    KUNDE_BETRAG,
    KUNDE_ABSENDER,
    KUNDE_SORTTEXT)
AS
select

KUNDE.IDX_KUNDE,
KUNDE.FIRMA,
KUNDE.KONTAKT_NACHNAME,
KUNDE.KONTAKT_VORNAME,
KUNDE.STRASSE,
KUNDE.HAUSNR,
KUNDE.PLZ,
KUNDE.ORT,
BLZ.KURZ,
BLZ.BLZ,
BLZ.PAN,
BLZ.BIC,
KUNDE.KONTO,
KUNDE.KONTAKT_VORNAME || ' ' || KUNDE.KONTAKT_NACHNAME,
KUNDE.STRASSE || ' ' || KUNDE.HAUSNR,
KUNDE.PLZ || ' ' || KUNDE.ORT,
GESCHLECHT.GESCHLECHT,
GESCHLECHT.ANREDE,
LAND.LAND,
KUNDE.EMAIL,
KUNDE.HOMEPAGE,
KUNDE.FESTNETZ,
KUNDE.HANDY,
KUNDE.KUNDE_MEMO,
KUNDE.ZEIT,
KUNDE.ZEIT_STRING,
KUNDE.PROJEKTZAHL,
KUNDE.PROJEKTBETRAG,
KUNDE.FIRMA || '  ·  ' || KUNDE.STRASSE || ' ' || KUNDE.HAUSNR || '  ·  ' || KUNDE.PLZ || ' ' || KUNDE.ORT,
B_TABELLEN.A_KUNDEN_SORTTEXT

from KUNDE
inner join GESCHLECHT on GESCHLECHT.IDX_GESCHLECHT = KUNDE.GESCHLECHT
inner join LAND        on LAND.IDX_LAND              = KUNDE.LAND
inner join BLZ         on BLZ.IDX_BLZ                = KUNDE.BANKVERBINDUNG
inner join B_TABELLEN on B_TABELLEN.BENUTZER        = KUNDE.BENUTZER
;

[waldforest]

Hallo,
vielen Dank, noch eine Nachfrage, Views dienen nur zum Anzeigen, ist also immer READ ONLY, oder lassen sich hierüber auch die Daten bearbeiten ?