Zugriff auf eine n:m Verknüpfung

[af0815]

Ich mache seit Jahren so und es funktioniert immer. Auch weiße ich oft das Update, Insert oder Delete SQL zu, da ich den internen SQL Parser nicht die Deutungshoheit überlasse. Damit kann ich auch Views updaten. Damit brauche ich auch kein ParseSQL.

[Sieben]

Dito, nur habe ich wie gesagt noch nie ein Param händisch erstellt oder erstellen müssen. Zuweisung von SQL mit entsprechender Syntax reicht aus, um gleich anschließend ParamByName() aufrufen zu können.

[six1]

übrigens:
SQL entwickle ich zuerst auf HeidiSQL und übernehme das dann einfach in den Programmcode.
Da kann man schön erkennen, was zurück kommt und wo man einen Bock drin hat...

[Luckner]

Hallo,

richtig, ich glaube es fehlt eine Where-Klausel. Stimmt auch, ich benutze FlameRobin und da kann man es auch schon ausprobieren. Hatte diese vergessen.

Gruß, Luckner

[Luckner]

Habe es folgendermassen gelöst:

('SELECT * FROM KUNDENSTAMM k ');
('join KUNDENLIEFERADRESSEN kl on k.ID=kl.IDKUNDEN ');
('join ADRESSENSTAMM a on a.ID = kl.IDADRESSEN ');
('where k.ID = ' + IntToStr(KundenID);

Jetzt sieht es gut aus.

Danke, Luckner

[charlytango]

Sorry, aber ich bin auch nach allen Hilfeversuchen immer noch verwirrt.

@Luckner Um qualifizierte Hilfe bei Datenbanken geben zu können fehlt für mich einerseits die betroffene Struktur der Datenbank (also die Tabellen die du abfragen willst). hier fragst du nach einer Abfrage von Lieferadressen und hier bringst du plötzlich eine neue Tabelle ADRESSENSTAMM ins Spiel.
Andererseits ist eine Abfrage völlig sinnfrei (wenns jetzt nicht gerade ein akademisches Beispiel für SQL ist) ohne erkennen zu können was und vor allem wie du etwas anzeigen willst.
Anders gesagt, eine kleine Skizze oder ein Screenshot deines Formulars wäre hilfreich - zumindest für mich.

Nur als Beispiel:
Bist du in einem Formular mit einer Kundenliste und willst irgendwie die Lieferadresse des jeweilig ausgewählten Kunden anzeigen oder bist du in einer Editiermaske eines Kunden bzw Rechnung und brauchst dort irgendwie eine Auswahl von Lieferadressen. Die gewünschte Darstellung bedingt die Art der Abfrage.

zudem bekommst du vielleicht auch nebenbei Tips wie man etwas idealerweise angeht, weil etliche Forumsteilnehmer schon viele Stunden mit der Optimierung solcher Systeme verbracht haben. Allein zum Thema "gemeinsamer Adressenstamm" hätte ich einiges beizutragen

...und ist die Frage (außer meinem Post) ausreichend beantwortet oder nicht?

Extempore:
In meinen DB-Applikationen versuche ich die abzufragenden Daten immer möglichst gering zu halten. Statt einer Gesamtliste aller Kunden zum Blättern (ist auch schon bei kleinen Datenmengen unhandlich) gibt es als Einstieg immer eine Möglichkeit das gewünschte Objekt (in deinem Fall den einen Kunden den du bearbeiten willst) mit harten (zB Kundennummer, Name, Kurzname) und weichen (Soundex, Teile von Ort, PLZ oder anderen Parametern) zu finden. Die eigentliche Bearbeitung des Kunden erfolgt dann in einem weiteren Formular. mehrere Kunden können immer auch gleichzeitig bearbeitet werden (was dann noch andere Probleme macht, aber das ginge hier zu weit). Ebenfalls versuche ich die SQL-Statements so zu schreiben dass sie unabhängig vom jeweiligen Dialekt der Datenbank sind. Damit kann man die dahinter liegende DB immer gegen eine andere (ggfs größere) austauschen. Sollte mal etwas vorkommen was nur durch Datenbank-Spezifika lösbar ist landet das idealerweise als View oder stored procedure in der DB, deren Ergebnis auch wieder nur eine Tabelle ist.

hope that helps anyway

[six1]

das "select *" würde ich so nicht machen. Besser du beschreibst, was du benötigst.

Ansonsten würde ich Params einsetzen. Der Vorteil ist, dass z.B. immer richtig maskiert wird.

('where k.ID = ' + IntToStr(KundenID);
zu
('where k.ID = :KID;' );
ParamByName('KID').asinteger:=KundenID;

[charlytango]

das "select *" würde ich so nicht machen. Besser du beschreibst, was du benötigst.

Ansonsten würde ich Params einsetzen. Der Vorteil ist, dass z.B. immer richtig maskiert wird.

Yeahhh !!!

[charlytango]

('SELECT * FROM KUNDENSTAMM k ');
('join KUNDENLIEFERADRESSEN kl on k.ID=kl.IDKUNDEN ');
('join ADRESSENSTAMM a on a.ID = kl.IDADRESSEN ');
('where k.ID = ' + IntToStr(KundenID);

Kann immer noch nicht verstehen wieso zum Abfragen der Lieferadressen bei bekannter KundenID der Kundenstamm als Junk mit abgefragt wird. Traust du der SQL Datenbank nicht?
Wenn ich ein komplexeres SQL-Statment entwickle hab ich auch immer Prüfspalten mit dabei um zu sehen ob ICH keinen Mist gebaut hab. Die fliegen im endgültigen Statement aber wieder raus.

So mal aus der Hüfte, unter Schätzung der Spaltennamen

Code: Alles auswählen

SELECT 
  k.PLZ
, k.Ort
, k.Strasse
, k.Hausnummer
, k.DerGanzeRest 
FROM ADRESSENSTAMM k 
JOIN KUNDENLIEFERADRESSEN kl ON kl.IDADRESSEN = k.IDADRESSEN
WHERE kl.ID = :KundenID;

oder auch andersrum, je nachdem wie der jeweilige Statement-Optimizer drauf ist

Code: Alles auswählen

SELECT 
  k.PLZ
, k.Ort
, k.Strasse
, k.Hausnummer
, k.DerGanzeRest 
FROM KUNDENLIEFERADRESSEN kl 
JOIN ADRESSENSTAMM k ON kl.IDADRESSEN = k.IDADRESSEN
WHERE kl.ID = :KundenID;

wobei ich das mit dem direkt integrierten Adressenstamm immer noch für bedenklich halte (auch aus beleghistorischer Sicht)

[af0815]

Params +1

"select *" für mich ein nogo