MySql-Abfrage geht nach DB-Update nicht mehr
Hallo folgende Abfrage hat seit Monaten problemlos funktioniert:
Wir haben ein Update unsere Datenbank gemacht. Seitdem kommt immer die Fehlermeldung:
Duplicate colum name 'id'
Hat jemand eine Idee?
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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 124396
Url: https://administrator.de/forum/mysql-abfrage-geht-nach-db-update-nicht-mehr-124396.html
Ausgedruckt am: 24.12.2024 um 01:12 Uhr
39 Kommentare
Neuester Kommentar
Na ja, BCCray,
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
...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
P.S. Wer schrotet denn da die SQLs zusammen? Stevie Wonder?
Grüße
Biber
Zitat von @BCCray:
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....
Würde ich mir auch wünschen, aber Du weißt ja wie Montage sind.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....
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
...
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
...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:
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
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
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 funktioniertNe 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.Ich wollte alle Informationen in einer Tabelle. In dieser DB wird viel mit ID`s geabrbeitet.
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...
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?
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?
neue DB: Datenbankversion 5.0.77-log
alte DB: Database version 4.1.22-standard-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
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
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
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"?Hallo an alle,
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.
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
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
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
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
Moin KikiMiki,
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
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
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:
In Deiner neuen Version hast Du die Unterabfragen xx und yy über die ProID verknüpft. Das findest Du hier in der Zeile
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
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
Da ich Eure DB hier nicht habe, ist das Ganze natürlich ungetestet, sollte aber so stimmen.
Gruß, Mad Max
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?
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
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