Hallo, Situation ist die aus ‘Hausverwaltung mit Hibiscus und H2’, bei einer einfachen Abfrage bekomme ich die Fehlermeldung "Ambiguous column name “KONTO_ID”…, dieses Feld gibt es in einer verbundenen Tabelle nochmal und ist nicht änderbar.
Bei Ausführung der Abfrage aus der Entwurfsansicht mit F5 funktioniert die Abfrage. Am Fehlen eines Alias dürfte es daher nicht liegen?
Ist es das gleiche Problem wie bei Firebird, s."Hdch ‘Abfragen’, S. 12?
Ohne den Code der Abfrage lässt sich nur vermuten: In den Datengrundlagen sind in beiden Tabellen die Feldnamen “KONTO_ID” und bei der Abfrage wird irgendwo nicht klar, welcher Tabelle die gewünschte “KONTO_ID” denn zugeordnet werden kann.
Willst Du dann noch aus so einer Abfrage eventuell eine Ansicht machen, dann bekommst Du das Problem, dass Ansichten grundsätzlich nur unterschiedlich bezeichnete Feldnamen haben dürfen. Du wirst also mit einem Alias arbeiten müssen.
Der Code der Abfrage ist:(nein-die Fehlermeldung):
Ambiguous column name “KONTO_ID”; SQL statement:
SELECT “KONTO”.“BEZEICHNUNG”, “UMSATZ”.“EMPFAENGER_NAME”, “UMSATZ”.“BETRAG”, “UMSATZ”.“ZWECK”, “UMSATZ”.“DATUM”, “UMSATZTYP”.“NAME”, “UMSATZ”.“KOMMENTAR”, “UMSATZTYP”.“KOMMENTAR” FROM “HIBISCUS”.“PUBLIC”.“UMSATZ” “UMSATZ” LEFT OUTER JOIN “HIBISCUS”.“PUBLIC”.“KONTO” “KONTO” ON “UMSATZ”.“KONTO_ID” = “KONTO”.“ID” LEFT OUTER JOIN “HIBISCUS”.“PUBLIC”.“UMSATZTYP” “UMSATZTYP” ON “UMSATZ”.“UMSATZTYP_ID” = “UMSATZTYP”.“ID” ORDER BY “UMSATZ”.“DATUM” DESC, “KONTO_ID” DESC [90059-197] ./connectivity/source/drivers/jdbc/Object.cxx:175
Lasse ich im Entwurfsmodus die Abfrage mit F5 ausführen, funktioniert sie.
Wie ist das mit dem Alias zu verstehen - das Konfliktffeld ist “KONTO_ID”, das wird in der Abfrage aber nicht angesprochen.?
Schau auf den Code ganz zum Schluss. Da steht eine Sortierung nach “KONTO_ID” ohne Benennung der entsprechenden Tabelle. Vielleicht “KONTO”.“KONTO_ID”?
1 Like
Danke für den Hinweis, -habe das mit base in der Entwurfsansicht erstellt, habe eigentlich nur das Datumsfeld aus ‘UMSATZ’ descending eingestellt, nicht “KONTO_ID”. Was kann [90059-197] dahinter bedeuten?
Und warum läuft es aus der Entwurfsansicht mit F5?
Bin morgen wieder dran…
Ich gehe davon aus, dass das genauso wie der Rest mit dem entsprechenden Zeilenverweis ‘175’ Informationen für Entwickler ist. Jedenfalls hängt das nicht mit der Abfrage selbst zusammen.
Wenn Du bei den Ansichten zwischen SQL und GUI hin und her schaltest wird der Code jedes Mal den Vorgaben der GUI angepasst. Ich klcke Abfragen bei vielen Feldern erst in der GUI zusammen und wechsele dann in den SQL-Modus. Öffne ich anschließend eine Abfrage wieder zum Bearbeiten, so öffne ich die Abfrage grundsätzlich nur noch im SQL-Modus. Dadurch habe ich den Code sicher wie er sein soll.
Das hört sich sehr vorsichtig an. Muss man denn Base auch bei Abfragen wie ein rohes Ei behandeln?
Da braucht man sich nicht wundern, dass es sich nicht durchsetzt!
Habe die Abfrage gelöscht und setze sie neu auf.
Mache trotzdem weiter mit Base, wegen der eigentlich großen Möglichkeiten
Danke, RobertG., für deine Erläuterungen!
Angesichts dieser Schwierigkeiten und deines vorsichtigen Vorgehens stellt sich die Frage, ob es nicht eine verbesserte Version des Report-Designers gibt. - Der war ja mal von Pentaho übernommen worden und -gegoogelt- zeigt sich, es gibt aktuell die Version 10.2.
Die scheint erheblich verbessert zu sein, kann u.a. sub-reports etc., spricht von einer ‘Pentaho HSQLDB sample database installed’, also deiner Standard-Datenbank hier:
https://docs.hitachivantara.com/r/en-us/pentaho-data-integration-and-analytics/10.2.x/mk-95pdia008/connect-to-a-data-source/jdbc
Dies gibt’s als developer edition zum freien download und probeweise als 30 day trial die enterprise-edition hier:
https://pentaho.com/pentaho-developer-edition/
Wäre es möglich, dass du und evtl. Villeroy das mal testet und einen Erfahrungsbericht bringt? Auch dazu, ob und wie sich das von LO ansprechen ließe?
Das System scheint die Datenbank-Anwendung vom Report her aufzuzäumen, also vom Ziel der DB-Anwendung her, was es für viele auch verständlicher machen würde, die meinen, ich hab’ doch Excel/Calc, was brauche ich eine komplizierte Datenbank…
Es gibt zur Zeit schon niemanden, der sich außer zur Behebung von neuen Bugs um den ReportBuilder bei Base kümmert. Das liegt auch daran, dass der ReportBuilder ein Java-Produkt ist. Der Weg ist ja gerade, die Abhängigkeit von Java zu lösen. Wenn ich allein die Probleme sehe, die von der Apple-Seite mit Java hier immer wieder auftauchen dann wäre ich auch eine Bindung an Java leid.
Da brauchten wir vermutlich eine ganz andere Zugriffsart. Ich selbst nutze den Report-Builder nur noch selten. Den Ausdruck mache ich über Makros in eine Writervorlage (mit Tabellen und Platzhaltern).