Sep 07, 2009, updated at Sep 09, 2009 (UTC)

7547

MySql-Abfrage geht nach DB-Update nicht mehr

Hallo folgende Abfrage hat seit Monaten problemlos funktioniert:

SELECT Projekt,pkey AS Schlüssel,reporter AS Autor,assignee AS Bearbeiter,
created AS Erstellt,updated AS Aktualisiert,Vorgangstyp,Lösung,Status,
Priorität,Komponente,betrifft_Version, Lösungsversion FROM

(SELECT *
FROM jiraissue k

LEFT OUTER JOIN (SELECT id, pname AS Projekt FROM project) l on (k.project= l.id)
LEFT OUTER JOIN (SELECT id, pname AS Vorgangstyp FROM issuetype) m on (k.issuetype= m.id)
LEFT OUTER JOIN (SELECT id, pname AS Lösung FROM resolution) o on (k.resolution= o.id)
LEFT OUTER JOIN (SELECT id, pname AS Status FROM issuestatus) u on (k.issuestatus= u.id)
LEFT OUTER JOIN (SELECT id, pname AS Priorität FROM priority) n on (k.priority= n.id)) yy
LEFT OUTER JOIN
(SELECT * FROM
(SELECT a.source_node_id, MAX(b.cname) AS Komponente
FROM nodeassociation a LEFT OUTER JOIN component b ON (a.sink_node_id = b.id)
WHERE association_type = 'IssueComponent'  
GROUP BY a.source_node_id) x
LEFT OUTER JOIN
(SELECT a.source_node_id, MAX( c.vname) AS Lösungsversion
FROM nodeassociation a LEFT OUTER JOIN projectversion c ON (a.sink_node_id = c.id)
WHERE association_type = 'IssueFixversion'  
GROUP BY a.source_node_id) y
ON (x.source_node_id=y.source_node_id)
LEFT OUTER JOIN
(SELECT a.source_node_id, MAX(c.vname) AS betrifft_Version
FROM nodeassociation a LEFT OUTER JOIN projectversion c ON (a.sink_node_id = c.id)
WHERE association_type = 'Issueversion'  
GROUP BY a.source_node_id) z
ON (x.source_node_id=z.source_node_id)) xx
ON (xx.source_node_id = yy.id)
WHERE Projekt ='Testprojekt'  
ORDER BY pkey DESC

Wir haben ein Update unsere Datenbank gemacht. Seitdem kommt immer die Fehlermeldung:

Duplicate colum name 'id'

Hat jemand eine Idee?

Please also mark the comments that contributed to the solution of the article

Content-Key: 124396

Url: https://administrator.de/contentid/124396

Printed on: April 26, 2024 at 14:04 o'clock

39 Comments

Latest comment

Servus,

verzeih mir kurz aber.... Ich kann dir leider nicht helfen, aber als ich diese Query gesehen habe....

looooooooool

Mehr Angaben hast du nicht????

Welche Datenbank z.B. würd helfen, von welcher Version auf welche geupdatet wurde....

Na ja, BCCray,

Zitat von @BCCray:

Würde ich mir auch wünschen, aber Du weißt ja wie Montage sind.
Außerdem würde ich an mySQL-Engines' Stelle, egal ob ich Version 3.5 oder 4.0 oder 5.1 wäre, immer den #1060 schmeissen, wenn mich jemand mit einem

(SELECT *
FROM jiraissue k
...

...und danach FÜNF Left Outer Joins auf Kaspertabellen mit jeweils "Select ID , name As Alias" belästigen würde.
Natürlich sind das Duplicate Columns in diesem SELECT - das Feld ID ist in dem "SELECT * " nicht eindeutig identifizierbar.

Wenn es VORHER nicht angemeckert wurde, war

entweder genau das ein Bug in der alten Version
oder ihr habt jetzt ein höheres WARNING_LEVEL als in der alten Version.

P.S. Wer schrotet denn da die SQLs zusammen? Stevie Wonder?

Grüße
Biber

DAS ist eindeutig die Query des Jahres *vote*

Bleibt eigentlich noch irgendwelche Datenbanktabellen unangetastet??? Da is ja das Kartesische Produkt um ein vielfaches kleiner als das

Hallo,

sorry wenn mein SQL-Statement nicht der "Norm" entspricht. Bin absoluter Newbie und hab mir die irgendwie zusammengeschustert und bisher hat Sie auch funktioniert. Ob die Abfrage gut oder schlecht ist kann ich nicht beurteilen...

Wäre euch für jeden Tipp dankbar...

Ist eine Mysql Datenbank...5. irendwas....

...5. irendwas....

Bitte versuch das genauer zu klären, es gibt bei den Subversions auch große Unterschiede.

Wir versuchen doch zu helfen, aber bei einer so "wartungsunfreundlichen" Query wärs besser, sich über die Query erst nochmal in Ruhe Gedanken zu machen ( ich denke das es einfacher ist, die Query umzuändern und zu verienfachen, da 6 Left outer Joins echt ned sein können......)

Greetz ;)

Moin KikiMiki,

hast ja Recht, unsere Lachtränen helfen Dir sicherlich nicht weiter.

Angenommen, wir wollten den möglichen Fehler in der Query meinetwegen ohne vernünftige Rahmeninformationen eingrenzen, dann ändere drei Details, die manchmal Empfindlichkeiten auslösen könnten:

Ersetze in der ersten Feldaufzählung "SELECT ...Priorität,Komponente,betrifft_Version..." alle "Feldname-komma-Feldname"-Abfolgen durch "feldname-komma-Leerzeichen-Feldname"
ersetze alle angesprochenen Namen mit ö, ü, ä durch gleichbedeutende mit oe, ue, ae z.b. bei "Lösung"
lass in den 5 left outer joins beim "select id, pname as weissdergates" das "id" weg - das Feld brauchst Du gar nicht.

Und unabhängig davon, ob die Query dann fliegt oder nicht -- überarbeite Dein Datenmodell!!
diese lustigen Nicht-ganz-so-ernstgemeinten-Foreignkeys, die auch alle NULL sein dürfen.... kann nicht sein.
Und wenn Du 27 Hilfstabellen hast, die nur aus "id" und "pname" bestehen, dann hat das auch Potentiale.
Das mag zwar im logischen Datenmodell so sein, aber definitiv nicht im Physischen.
[Aber das möge der nächste Thread werden].

Aber ich stimme BCCray zu - so gelacht hab ich seit dem letzten F.D.P.-Wahlprogramm nicht mehr.

grüße
Biber

Ok,
eigentlich bin ich kein Komiker, aber anscheinend kann ich das ganz gut

wie gesagt ich bin absoluter SQL-Anfänger ich war nur froh das diese Anfrage das ausgespuckt hat was ich wollte....

Ich wollte alle Informationen in einer Tabelle. In dieser DB wird viel mit ID`s geabrbeitet.

Wenn in meiner Tabelle steht: Projekt =1, Lösung =2 , Bearbeiter =44

kann niemand damit was anfangen, Durch die JOINS kam so was zustande;
Projekt = Auto, Lösung = behoben , Bearbeiter = Müller usw.

Es ist keine DB mit 3 Tabellen, das ganze ist ein Bugtrackingtool was recht komplex aufgebaut ist.

Ich wäre auch glücklich wenn man meine Abfrage schlnaker und schneller machen könnte...

wie gesagt ich bin absoluter SQL-Anfänger ich war nur froh das diese Anfrage das ausgespuckt hat was ich wollte....

Mann, des würd ja ned mal ein MySQL-Pro hinbekommen - wie gesagt, so eine Query ist mir noch nie untergekommen

Ich wäre auch glücklich wenn man meine Abfrage schlnaker und schneller machen könnte...

Das ist die Kunst bei SQL

Ich will echt ned wissen was das für ne Querylaufzeit wäre wenns funktioniert

Ne im Ernst, nimm die Ratschläge von Biber mal in Angriff. Wenn ich da mal grob drüberlese so denk ich das du eigentlich mehr selektierst bzw. dir in den Speicher holst als du jemals brauchen wirst. Ich hab grad nebenbei ein wenig versucht Ordnung in deine Query zu bekommen, um mir des ganze einfacher zu visualisieren... ich geb auf.....

Das optimieren der Query, darum wirst du allein ned rumkommen - ich hab leider keine Wissen über die Struktur der Datenbank, deine Tabellen, Primary-Keys, etc.

Vielleicht hast du ja jemanden, der dir hier helfen kann und schon Erfahrung mit MySQL aufweist. Dem kannst du dann das Schema mal zeigen. Ich denke nämlich, das sich viele deiner Abfragen sowieso automatisch ergeben.

Das Problem mit dem Dublicate column name wirst du wahrscheinlich jedoch nicht so schnell gelöst bekommen, als wenn du diese Query optimierst. Ich denk damit ist dir (und so nebenbei - deiner Datenbank) sehr viel mehr geholfen. Auch wird sie dann wartbarer ;)

Ich muss hier passen - kann hier keine Hilfe leisten....

Aber rein informativ - halt mich (bzw. uns, wenns andere interresiert) auf den laufenden!

Zitat von @KikiMiki:

Ich wollte alle Informationen in einer Tabelle. In dieser DB wird viel mit ID`s geabrbeitet.

Der Gedanke ist ja im Ansatz richtig.
Aber

nur weil es IDs sind, müssen sie doch nicht in jeder Drömel-Tabelle auch "ID" heißen.
und wenn es Fremdschlüssel sind, dann kann doch JEDER Wert referenziert werden (z.B. Status 0 = "unbekannt", 1="angefangen"....7="fertig") WozuTF sollen denn da LEFT OUTER JOINS nötig sein??? Was sollen denn NULL-Werte bedeuten wenn nicht "unbekannt"??
Und nochmals wozuTF sind denn für einfache Kennzeichentabellen (nur id+name) mit identischer Struktur physikalisch einzelne Tabellen nötig??? Das bekommst Du doch in EINER Tabelle mit einem zusätzlichen Kennzeichenfeld unter (Kennz 22= "issuetype" mit Id und name, Kennz 23=Resolutiontype mit id und name...).

Es ist keine DB mit 3 Tabellen, das ganze ist ein Bugtrackingtool was recht komplex aufgebaut ist.

Das hättest Du nicht erwähnen müssen, das ist unübersehbar. Aber dieses Rad ist doch weder neu noch nobelpreisverdächtig.
Muss jeder Praktikant zum Warmwerden machen.
Dennoch kann/muss/sollte man/frau doch unterscheiden können zwischen den Logischen Zusammenhängen und den physisch erforderlichen Tabellen.
Oder habt ihr nur ein und dasselbe Datenmodell für beides?

Grüße
Biber

P.S. Sorry, wenn ich mich so aufrege, aber DB-Modellierung und DB-Tuning ist eins meiner Hobbys...

P.S. Sorry, wenn ich mich so aufrege, aber DB-Modellierung und DB-Tuning ist eins meiner Hobbys...

Oh jaaaa sag mir mehr schmutzige Namen

grrrr

Hallo,

wenn ich mir das ansehe kommt mir irgendwie der Gedanke,
da war doch mal was mit diesen Normalformen

WIe war das ab einem gewissen Punkt macht eine Denormalisierung mehr Sinn.

Achja nebenbei setz deinen SQL Query mal unter code tags damit er hervorgehoben wird.

Nach welchen Kriterien hast du denn die Tabellen aufgebaut?
Hast du dich mit Grundlegender Datenbankthematik mal befasst?

Hallo an alle,

also wie gesagt ich bein kein Datenbank-Profi (totaler Anfänger) habe mir das irgendwie zusammengebaut. ES HAT JA AUCH funktioniert.
Bloß seit dem DB-Update geht die Abfrage nicht mehr...

neue DB: Datenbankversion 5.0.77-log
alte DB: Database version 4.1.22-standard-log

Ich weiß, mein SQL ist schlecht, aber es hat bisher ihren Zweck erfüllt.

Das Ergenis der SQL-Abfrage wird in Excel importiert und mit Pivot`s ausgewertet. Alles automatisch...

Ich möchte einfach nur die Abfrage zum laufen bringen.

Wenn ich die gleiche Abfrage (wie oben gepostet) auf unserer alten DB ausführe, geht diese ohne Probleme...

neue DB: Datenbankversion 5.0.77-log
alte DB: Database version 4.1.22-standard-log

Umstellung von MySQL 4.xx auf 5.xx

In der 5er Version wurde die Abarbeitung der Joins überarbeitet.

Von daher kommst du leider um eine Umstellung deiner Query nicht herum... Tut mir leid....

Hier noch was für dich...
Joins in MySQL
Join Optimierung

Greetz

Danke für den Hinweis

hast du auch eine Idee wie ich das ändern könnte?

Ich hatte damals das gleiche Problem bzw. wars so, das ich auf dem Testsystem MySQL 5 installiert hatte, das Produktivsystem war jedoch leider noch ne 4er Version,
welche ich lt. dem dortigen Admin nicht updaten durfte (so eine Flachzange echt...)

Bei mir war halt der Vorteil, das die Querys nicht eine ganze Seite lang waren, und ein Umschreiben hier relativ schnell von statten...

Aus oben genannten Gründen kann ich dir leider hier nicht weiter helfen, die Umstellung der Query wirst du wohl oder übel selbst machen (auch wenn das fast schon pervers is)

Am besten wäre es, wenn du jemanden zur Hand hättest, der schon einiges an Erfahrung in Bereich Datenbanken und MySQL hat.

Mehr kann ich dir da wirklcih leider nicht helfen....

Greetz

Ok, trotzdem vielen dank für deine Mühe

Kein Problem ;)
Und ich denke ein "viel Glück" bzw "viel Erfolg" ist in deinem Fall angebracht

Hau rein!

Greetz

BCC

Zitat von @KikiMiki:

Hallo an alle,

Das Ergenis der SQL-Abfrage wird in Excel importiert und mit Pivot`s ausgewertet. Alles automatisch...

Kennst Du die Bremer Redewendung "Ich könnt' ins Essen brechen"?

Ich möchte einfach nur die Abfrage zum laufen bringen.

Ich finde auch, wir beschränken uns erstmal auf dieses Problem.
Wenn Du dann immer noch Lust hast, dann können wir mal in zwei neuen Threads

das Datenmodell incl der von BCCray angedeuteten De-Normalisierung angehen, ein paar SET-Felder einbauen etc
und vielleicht auch über diesen merkwürdigen Prozess philosophieren, mit dem eine Datenbank mit Excel-Pivot-Tabellen durchschrapelt wird

Ich hatte Dir 3 Tipps zum Herantasten/Ausschliessen von Kompat-Fehlern gepostet.
Welche davon bringen keine Änderung?

Grüße
Biber

@ Biber

ich versteh jetztz ehrlich gesagt nicht wieso du ins Essen brechen willst.

Ich habe ein Skript in diesem ist mein SQL hinterleget. Das Skript verbindet sich mit der DB und schreibt mir die Daten in eine xls. Das funktioneirt auch alles.

Muss nur meine SQL-Abfrage zum laufen bringen. Wenn die SQl auf der Db geht kann ich sie in mein Skript einbauen.

Um das Skript geht es hier ja auch gar nicht.
Ich kann es nochmal nur wiederholen ich hab null Ahnung von SQl, was ihr sicherliche auch schon zu genüge bemerkt habt.
Ich dachte vielleicht habt ihr eine Lösung wenn ihr meine Abfrage sieht.

Ich habe inzwischen begriffen das meine Abfrage der größte Mist überhaupt ist. HAB ES VERSTANDEN.

Ich finde es ehrlich gesagt auch blöd wenn alles in Frage gestellt wird. Wir fahren nun mal Pivotauswertungen in Excel. Hat bisher prima geklappt nur schade das es jetzt wegen der SQL-Abfrage nicht mehr geht...

Moin kikiMiki,

sorry, meinen letzten Kommentar habe ich stilistisch und formal äußerst ungeschickt aufgebaut.
Hätte ich geahnt, dass Du nur die erste Hälfte liest, dann hätte ich eine andere Reihenfolge gewählt.

Bitte lies noch mal meinen Kommentar von unten nach oben und beschränke Dich auf die beiden Zeilen vor dem "Grüße Biber".

Zusatzfrage: Welche der 5 Left-outer-Join-IDs ist ganz unten gemeint in "....ON (xx.source_node_id = yy.id)". ??

Gruß
Biber

Moin KikiMiki,

Deine Frage wurde ja nun in einem Crosspost in einem Nachbarforum für Deine Belange hinreichend beantwortet.

Kann der Beitrag hier dann geschlossen/kompostiert werden?

Grüße
Biber

Hallo,

ja einer konnte mir zum Glück helfen

Falls es euch interessiert hier der Code, auch wenn es sicherlich kopfschütteln verursacht ;) Aber es liefert mir das nötige Ergebnis

SELECT Projekt,pkey AS Schlüssel,reporter AS Autor,assignee AS Bearbeiter,
created AS Erstellt,updated AS Aktualisiert,Vorgangstyp,Lösung,Status,
Priorität,Komponente,betrifft_Version, Lösungsversion
FROM (SELECT *
FROM jiraissue k
LEFT OUTER JOIN (SELECT id as ProID,pname AS Projekt FROM project) l on (k.project= l.ProID)
LEFT OUTER JOIN (SELECT id as IssID, pname AS Vorgangstyp FROM issuetype) m on (k.issuetype= m.IssID)
LEFT OUTER JOIN (SELECT id as ResID, pname AS Lösung FROM resolution) o on (k.resolution= o.ResID)
LEFT OUTER JOIN (SELECT id as StaID, pname AS Status FROM issuestatus) u on (k.issuestatus= u.StaID)
LEFT OUTER JOIN (SELECT id as PriID, pname AS Priorität FROM priority) n on (k.priority= n.PriID)
) yy
LEFT OUTER JOIN
(SELECT * FROM
(SELECT a.source_node_id AS Komponente, MAX(b.cname)
FROM nodeassociation a
LEFT OUTER JOIN component b ON (a.sink_node_id = b.id)
WHERE association_type = 'IssueComponent'
GROUP BY a.source_node_id
) x
LEFT OUTER JOIN
(SELECT a.source_node_id AS Lösungsversion, MAX( c.vname)
FROM nodeassociation a LEFT OUTER JOIN projectversion c ON (a.sink_node_id = c.id)
WHERE association_type = 'IssueFixversion'
GROUP BY a.source_node_id
) y ON (x.Komponente=y.Lösungsversion)
LEFT OUTER JOIN
(SELECT a.source_node_id AS betrifft_Version, MAX(c.vname)
FROM nodeassociation a LEFT OUTER JOIN projectversion c ON (a.sink_node_id = c.id)
WHERE association_type = 'Issueversion'
GROUP BY a.source_node_id
) z ON (x.Komponente=z.betrifft_Version)
) xx ON (xx.Komponente=yy.ProID)
WHERE Projekt ='Test'
ORDER BY pkey DESC

Moin KikiMiki,

Falls es euch interessiert hier der Code, auch wenn es sicherlich kopfschütteln verursacht ;)

Danke für das Posten der Lösung.
Und was das Thema Kopfschütteln betrifft - Deine Fragestellung war ja: "Wie bekomme ich die bisher funktionierende Query wieder zum Fliegen?"

Und auf genau diese Frage gab es eine hilfreiche Antwort (in dem Crosspost).

Die Dir aufgedrängten weitergehenden Fragen müssen wir ja nicht behandeln.
ist ja für einen Prototyp durchaus okay.
Aber bevor ihr mit diesem Ticketsystemchen produktiv geht, solltet ihr nochmal einen Blick auf Datenmodell, Zugriffspfade, Performanz und mittelfristige Wartbarkeit dieses Gestrunkeles werfen.

Meine Praktikantinnen bekommen jedenfalls nur ein statt zwei Amarettini zum Cappuccino, wenn sie so etwas als final version anschleppen.

Grüße
Biber

Hi Biber,

wie gesagt hauptsache ich bekomme mein Ergebnis

Wir nutzten JIRA als "Ticketsystem"

http://www.atlassian.com/software/jira/

Eine ziemlich komplexe DB-Struktur. Das alles zu erklären was ich aus dieser DB brauche und die ganzen Sonderfälle zu beachten würde jetzt sicherliche den Rahmen sprengen

Ob die DB-Struktur von JIRA gut oder schlecht ist kann ich nicht beantworten, da ich das nicht fachmännisch beurteilen kann.

Bin nur froh das meine Abfrage wieder geht....

Gruß

KikiMiki

Moin KikiMiki,

schön, daß sie wieder ein Ergebnis liefert, wenn Du aber die hier angegeben Abfrage verwendest, ist es nicht das richtige. In Deiner alten Abfrage waren die Aliasse Komponente, Lösungsversion und betrifft_Version auf die MAX (...)-Aggregate gesetzt, in der neuen sind sie auf den source_node_id-Spalten.

Da ich Knobelaufgaben liebe, hab ich mir die Abfrage auch mal angetan:

SELECT	l.pname AS Projekt,
	k.pkey AS Schlüssel,
	k.reporter AS Autor,
	k.assignee AS Bearbeiter,
	k.created AS Erstellt,
	k.updated AS Aktualisiert,
	m.pname AS Vorgangstyp,
	o.pname AS Lösung,
	u.pname AS Status,
	n.pname AS Priorität,
	x.Komponente,
	z.betrifft_Version,
	y.Lösungsversion
FROM	jiraissue k
	LEFT OUTER JOIN project l ON k.project = l.id
	LEFT OUTER JOIN issuetype m ON k.issuetype = m.id
	LEFT OUTER JOIN resolution o ON k.resolution = o.id
	LEFT OUTER JOIN issuestatus u ON k.issuestatus = u.id
	LEFT OUTER JOIN priority n ON k.priority = n.id
	LEFT OUTER JOIN (
		SELECT	a.source_node_id,
			MAX(b.cname) AS Komponente
		FROM	nodeassociation a
			LEFT OUTER JOIN component b ON a.sink_node_id = b.id
		WHERE	a.association_type = 'IssueComponent'  
		GROUP BY a.source_node_id
		) x ON k.project = x.source_node_id
	LEFT OUTER JOIN (
		SELECT	a.source_node_id,
			MAX(c.vname) AS Lösungsversion
		FROM	nodeassociation a
			LEFT OUTER JOIN projectversion c ON a.sink_node_id = c.id
		WHERE	a.association_type = 'IssueFixversion'  
		GROUP BY a.source_node_id
		) y ON x.source_node_id = y.source_node_id
	LEFT OUTER JOIN (
		SELECT	a.source_node_id,
			MAX(c.vname) AS betrifft_Version
		FROM	nodeassociation a
			LEFT OUTER JOIN projectversion c ON a.sink_node_id = c.id
		WHERE	a.association_type = 'Issueversion'  
		GROUP BY a.source_node_id
		) z ON x.source_node_id = z.source_node_id
WHERE	l.pname = 'Testprojekt'  
ORDER BY k.pkey DESC

In Deiner neuen Version hast Du die Unterabfragen xx und yy über die ProID verknüpft. Das findest Du hier in der Zeile

		) x ON k.project = x.source_node_id

wieder. Wenn die Verknüpfung über eine andere der fünf IDs in xx erfolgen sollte, dann müßte das da angepaßt werden.

Da ich Eure DB hier nicht habe, ist das Ganze natürlich ungetestet, sollte aber so stimmen.

Gruß, Mad Max

Hi Mad Max,

erstmal vielen Dank für deine Mühe. Unglaublich

Hab deinen Code eingefügt.

Kommt aber folgende Fehlermeldung

FUNCTION db_jira.MAX does not exist

Hmpf, ja, ist ja MySQL. Ich bevorzuge der Lesbarkeit wegen Leerzeichen zwischen Funktionen und ihren Klammern, das mag MySQL aber nicht. Wenn Du also das Leerzeichen hinter MAX entfernst, sollte es funktionieren.

Hi Mad Max,

hab ich gmeacht. Jetzt kommt eine neue Fehlermeldung:

Unknown column 'y.betrifft_Version' in 'field list'

So ist das mit ungetesteten Abfragen, direkt über dem "FROM" sind die beiden Aliasse vertauscht, richtig muß es sein:

	...
	z.betrifft_Version,
	y.Lösungsversion
FROM ...

Du bist ein Genie.
Es klappt
Vorher dauerte die Abfrage 30 Sekunden - jetzt nur noch 2 Sekunden

Bloß ein Problem ist mir aufgefallen...

Die Komponente, betrifft_Version und Lösungsverision werden immer als NULL zurückgegeben....
War auch so in meiner geänderten Abfrage so. Ist mir erst jetzt aufgefallen

In meiner Ursprungsabfrage, siehe ganz oben (1. Eintrag) werden aber die Komponente, Lösungsversion und betrifft_Version ausgegeben...

Ist da noch ein Denkfehler drin?

Da kommt das Problem raus, das nach der Versionsumstellung zum Fehler geführt hat. Die beiden Unterabfragen xx und yy wurden ursprünglich über "xx.source_node_id = yy.id" verknüpft, wobei yy.id aber nicht eindeutig ist. yy.id kann also sein k.project, k.issuetype, k.resolution, k.issuestatus oder k.priority. Und da wir die Spalten in der Tabelle jiraissue nicht kennen, kann da auch noch mal eine id drin sein (k.id).

Du mußt also schauen, daß Du in Zeile 27 in obigem Code (k.project = x.source_node_id) die verschiedenen IDs ausprobierst, die in Frage kommen. Mein Favorit ist dabei "k.id = x.source_node_id".

Gruß, Mad Max

@ MadMax

du machst deinem Nick alle Ehre

Hut ab und dickes fettes Dankeschön.
Alles wird so ausgegeben wie ich es brauche.

Und dazu noch viel schneller als vorher....

Du hast mir einen riesen gefallen getan. Nochmals Danke!

Gruß

KikiMiki

+1 für Mad Max

echt gute Arbeit!

Mir ist das jetzt sehr peinlich

Ich habe nur die ersten Ergebnisse überflogen. Am Anfang stimmt alles. Blos hab ich jetzt in meinem Ergebnis ID`s die keine Lösungsversion oder betrifft_Version haben
Schaue ich aber in die Anwendung dann haben diese ID´s eine Lösungsversion oder betrifft_Version

Bei allen ID`s werden die Komponenten nach der SQL-ausführung korrekt abgebildet

Die Lösungsversion oder betrifft_Version zum Teil

Hier nochmal mein Code:

SELECT	l.pname AS Projekt,
	k.pkey AS Schlüssel,
	k.reporter AS Autor,
	k.assignee AS Bearbeiter,
	k.created AS Erstellt,
	k.updated AS Aktualisiert,
	m.pname AS Vorgangstyp,
	o.pname AS Lösung,
	u.pname AS Status,
	n.pname AS Priorität,
	x.Komponente,
	z.betrifft_Version,
	y.Lösungsversion
FROM	jiraissue k
	LEFT OUTER JOIN project l ON k.project = l.id
	LEFT OUTER JOIN issuetype m ON k.issuetype = m.id
	LEFT OUTER JOIN resolution o ON k.resolution = o.id
	LEFT OUTER JOIN issuestatus u ON k.issuestatus = u.id
	LEFT OUTER JOIN priority n ON k.priority = n.id
	LEFT OUTER JOIN (
		SELECT	a.source_node_id,
			MAX(b.cname) AS Komponente
		FROM	nodeassociation a
			LEFT OUTER JOIN component b ON a.sink_node_id = b.id
		WHERE	a.association_type = 'IssueComponent'  
		GROUP BY a.source_node_id
		) x ON k.id = x.source_node_id
	LEFT OUTER JOIN (
		SELECT	a.source_node_id,
			MAX(c.vname) AS Lösungsversion
		FROM	nodeassociation a
			LEFT OUTER JOIN projectversion c ON a.sink_node_id = c.id
		WHERE	a.association_type = 'IssueFixversion'  
		GROUP BY a.source_node_id
		) y ON x.source_node_id = y.source_node_id
	LEFT OUTER JOIN (
		SELECT	a.source_node_id,
			MAX(c.vname) AS betrifft_Version
		FROM	nodeassociation a
			LEFT OUTER JOIN projectversion c ON a.sink_node_id = c.id
		WHERE	a.association_type = 'Issueversion'  
		GROUP BY a.source_node_id
		) z ON x.source_node_id = z.source_node_id
WHERE	l.pname = 'Test'  
ORDER BY erstellt DESC

Boah, ich lauf hier ja rot an. Aber freut mich, daß es läuft

Muss ich bei betrifft_Version und Lösungsverison noch was ändern?
Damit diese alle korrekt angeziegt werden?
Ich erkenn den Fehler nicht

Hi Mad Max.

Hab jetzt die Auffäligkeit im Ergebnis gefunden....

Und zwar wenn ein Vorgang (ID) eine Komponente hat, dann werden die Lösungsversion und betrifft_Version korrekt angezeigt.

Hat eine ID aber keine Komponente dann findet er immer KEINE Lösungsversion und betrifft_Version.

Es gibt aber ID`s die keine Komponente haben dafür aber eine Lösungsversion oder betrifft_Version

Kann man das im SQL irgendwie abfangen?

Gruß

Die Verknüpfungen sind wie in der alten Version, da sollte das dann auch so gewesen sein wie jetzt.

Aber natürlich kann man das ändern. Ändere die Zeilen 35 und 43 in:

...
		) y ON k.id = y.source_node_id
...
		) z ON k.id = z.source_node_id
...

@ MadMax

ich taufe dich um in KingMax

Genau das war es...Hab mich schon tausend mal bedankt. Bedanke mich jetzt noch zusätzlich eine Millionen mal

Super das es Leute wie dich gibt die einem so helfen

Respekt!!!!

German solved Question Databases Development