5
Unzulässiges Einklammern des Namens Select
Hilfe!!!
Irgendwie spinnt eine Abfrage, ACCESS mag sie gar nicht, weiss aber nicht wieso...
Wisst Ihr Rat?
Schönen Gruß,
stevens
Ominöse Dinge passieren: Ich speichere folgende Abfrage ab:
SELECT A.*
FROM LyoTable AS A, (SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
FROM Lyotable
GROUP BY [Lot Number]) AS B
WHERE (A.[Lot Number]=B.[Lot Number] AND A.[Start Date]+ A.[Start Time] = B.StartDateTime);
und ACCESS ersetzt einfach die Klammer um (SELECT.... ] ) mit [SELECT.... ] ]. wie folgt:
SELECT A.*
FROM LyoTable AS A, [SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
FROM Lyotable
GROUP BY [Lot Number] ]. AS B
WHERE (A.[Lot Number]=B.[Lot Number] AND A.[Start Date]+ A.[Start Time] = B.StartDateTime);
und wirft dann beim Versuch, diese Abfrage erneut zu öffnen, den Fehler: "Unzulässiges Einklammern des Namens 'Select [Lot Number'."
Könnt Ihr Euch darauf einen Reim machen? ACCESS will dann auch gar nicht mehr diese Abfrage öffnen...
SELECT A.*
FROM LyoTable AS A, (SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
FROM Lyotable
GROUP BY [Lot Number]) AS B
WHERE (A.[Lot Number]=B.[Lot Number] AND A.[Start Date]+ A.[Start Time] = B.StartDateTime);
und ACCESS ersetzt einfach die Klammer um (SELECT.... ] ) mit [SELECT.... ] ]. wie folgt:
SELECT A.*
FROM LyoTable AS A, [SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
FROM Lyotable
GROUP BY [Lot Number] ]. AS B
WHERE (A.[Lot Number]=B.[Lot Number] AND A.[Start Date]+ A.[Start Time] = B.StartDateTime);
und wirft dann beim Versuch, diese Abfrage erneut zu öffnen, den Fehler: "Unzulässiges Einklammern des Namens 'Select [Lot Number'."
Könnt Ihr Euch darauf einen Reim machen? ACCESS will dann auch gar nicht mehr diese Abfrage öffnen...
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 139550
Url: https://administrator.de/contentid/139550
Printed on: April 16, 2024 at 14:04 o'clock
5 Comments
Latest comment
Die erste Antwort war etwas... unausgereift...
So, jetzt:
Abgesehen von dem SELECT, was hier wirklich zu viel ist passen da noch ein paar andere Sachen nicht.
Mal das offensichtliche:
Was soll die Abfrage eigentlich rausschmeissen? Ich hab so den Eindruck du versuchst mehrere Abfragen in eine einzige zu packen.
So, jetzt:
Abgesehen von dem SELECT, was hier wirklich zu viel ist passen da noch ein paar andere Sachen nicht.
Mal das offensichtliche:
Zitat von @stevensqwe:
... FROM LyoTable AS A, (SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
Mit dem Teil willst du anscheinend 2 Felder zu einem verbinden. Das geht nicht mit "+" sondern mit "&".... FROM LyoTable AS A, (SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
Was soll die Abfrage eigentlich rausschmeissen? Ich hab so den Eindruck du versuchst mehrere Abfragen in eine einzige zu packen.
Moin,
der SELECT ist an der Stelle schlichtweg falsch.. was genau willst du denn mit damit erreichen?
lg,
Slainte
der SELECT ist an der Stelle schlichtweg falsch.. was genau willst du denn mit damit erreichen?
lg,
Slainte
Moin stevensqwe,
jepp, da hast du den Redmonder PraktikantInnen wieder voll in den Schritt gefasst.
der Parser (=Syntaxprüfer und Übersetzer in Richtung Datenbankengine) der JET-Datenbank hat ein Problem damit, eine Query richtig mit einer Subquery zu verknibbeln, wenn denn die SubQuery selbst Feldnamen in eckigen Klammern enthält.
Konkreter:
--> was hier stört, sind die ganzen "[" und "]"s in der Subquery, die letzten Endes unter dem Alias B angesprochen wird.
Und die sind nur nötig, weil irgendeine Schafsnase unbedingt meinte, Datenbankfeldnamen mit "Leerzeichen im Namen" wie z.B. "Start Time" wären total angesagt in der Szene.
(Ich sprach kurz in dem Vorgängerthread darüber, glaube ich.)
Abhilfe:
Meiner unmaßgeblichen Meinung nach wäre das Problem ohne "Feldnamen in eckigen Brackets" gar nicht aufgetreten. und wenn diese wiederum nur nötig sind wegen dieser Leerzeichen... dann zwei oder drei Lösungsansätze:
Grüße
Biber
jepp, da hast du den Redmonder PraktikantInnen wieder voll in den Schritt gefasst.
der Parser (=Syntaxprüfer und Übersetzer in Richtung Datenbankengine) der JET-Datenbank hat ein Problem damit, eine Query richtig mit einer Subquery zu verknibbeln, wenn denn die SubQuery selbst Feldnamen in eckigen Klammern enthält.
Konkreter:
SELECT A.*
FROM LyoTable AS A,
(SELECT [Lot Number], Max([Start Time] +[Start Date]) AS StartDateTime
FROM Lyotable
GROUP BY [Lot Number])
AS B
WHERE
(A.[Lot Number]=B.[Lot Number]
AND
A.[Start Date]+ A.[Start Time] = B.StartDateTime);--> was hier stört, sind die ganzen "[" und "]"s in der Subquery, die letzten Endes unter dem Alias B angesprochen wird.
Und die sind nur nötig, weil irgendeine Schafsnase unbedingt meinte, Datenbankfeldnamen mit "Leerzeichen im Namen" wie z.B. "Start Time" wären total angesagt in der Szene.
(Ich sprach kurz in dem Vorgängerthread darüber, glaube ich.)
Abhilfe:
Meiner unmaßgeblichen Meinung nach wäre das Problem ohne "Feldnamen in eckigen Brackets" gar nicht aufgetreten. und wenn diese wiederum nur nötig sind wegen dieser Leerzeichen... dann zwei oder drei Lösungsansätze:
- statt auf Tabellen lieber auf Eins-Zu-Eins-Views (=heißen in Access auch "Abfragen") gehen, in denen die Feldnamen keine Leerzeichen mehr haben. Also "StartDate" statt "Start date"; "Lotnumber" statt "Lot Number" heißen
- Oder aber die Subquery auslagern in eine eigenständige Query, i.e das "SELECT [Lot Number] as LotNumber, Max([Start Time] +[Start Date]) AS StartDateTime FROM Lyotable GROUP BY [Lot Number] " in ein neues Abfrage-SQL-Fenster copy&pasten, Abfrage speichern als "LyoTableGroupedbyDateTime" und in der Query oben diesen Namen einsetzen
- oder aber tabula rasa machen und diese mistigen Leerzeichen endlich mal in den Tabellen resp LyoTable selbst rauswerfen (Felder umbenennen... natürlich auch in evtl Applikationen, Queries etc.)
Grüße
Biber
Danke Euch für die Hilfe!
Wenn das ein Parser Problem ist, kann ich wenigstens nachvollziehen, was ACCESS da im Hintergrund leistet bzw. nicht leistet...
und am sinnvollsten, die Leerzeichen einfach wegzulassen, hätte nicht gedacht, dass das den Parser durcheinander bringen könnte.
Danke und Gruß,
stevens
Wenn das ein Parser Problem ist, kann ich wenigstens nachvollziehen, was ACCESS da im Hintergrund leistet bzw. nicht leistet...
und am sinnvollsten, die Leerzeichen einfach wegzulassen, hätte nicht gedacht, dass das den Parser durcheinander bringen könnte.
Danke und Gruß,
stevens
Moin stevensqwe,
Da kannst du schon mal ein Auge zudrücken.
Wir können doch froh sein, dass überhaupt noch engagierte Unternehmen jungen Leuten, die sonst chancenlos auf dem ersten bis dritten Arbeitsmarkt wären, einen Ausbildungsplatz resp. eine Spielwiese bereitstellen.
Obwohl.... bei manchen Redmondern Programmen denk ich mir auch: Hey, eine neue Halfpipe oder ein Bolzplatz hätte den Kidz genauso viel Freude gemacht.
Grüße
Biber
hätte nicht gedacht, dass das den Parser durcheinander bringen könnte.
Na ja, ist ja kein Parser, der von Profis zusammengestoppelt wurde....Da kannst du schon mal ein Auge zudrücken.
Wir können doch froh sein, dass überhaupt noch engagierte Unternehmen jungen Leuten, die sonst chancenlos auf dem ersten bis dritten Arbeitsmarkt wären, einen Ausbildungsplatz resp. eine Spielwiese bereitstellen.
Obwohl.... bei manchen Redmondern Programmen denk ich mir auch: Hey, eine neue Halfpipe oder ein Bolzplatz hätte den Kidz genauso viel Freude gemacht.
Grüße
Biber