UNION SELECT Abfrage bringt Fehler "... konnte das Objekt '' nicht finden ..."

[Sebastian Brandt]

Habe ein Problem mit folgender Abfrage (SQL-Ansicht):

SELECT tblAdressen.AdrNr, tblAdressen.Nachname, tblAdressen.Vorname,
tblAdressen.AKzID, tblAdressen.SozID, tblAdressen.StrßID,
tblAdressen.OrtID, tblAdressen.GebDatum, tblAdressen.AnrBriefkopf,
tblAdressen.[Telefon 1], tblAdressen.Bemerkungen
FROM tblAdressen
WHERE (((tblAdressen.Nachname) Like "*" & [Filter: Name/Bezeichnung
oder frei lassen:] & "*") AND ((tblAdressen.OrtID) Like "*" & [Filter:
PLZ und/oder Ort oder freilassen:] & "*"))

UNION SELECT tblAdressenDiv.AdrNr, tblAdressenDiv.Nachname,
tblAdressenDiv.Vorname, tblAdressenDiv.AKzID, tblAdressenDiv.SozID,
tblAdressenDiv.StrßID, tblAdressenDiv.OrtID, tblAdressenDiv.GebDatum,
tblAdressenDiv.AnrBriefkopf, tblAdressenDiv.[Telefon 1],
tblAdressenDiv.Bemerkungen
FROM tblAdressenDiv
WHERE (((tblAdressenDiv.Nachname) Like "*" & [Filter: Name/Bezeichnung
oder frei lassen:] & "*") AND ((tblAdressenDiv.OrtID) Like "*" &
[Filter: PLZ und/oder Ort oder freilassen:] & "*"))

UNION SELECT tblAdressenAnw.AdrNr, tblAdressenAnw.Nachname,
tblAdressenAnw.Vorname, tblAdressenAnw.AKzID, tblAdressenAnw.SozID,
tblAdressenAnw.StrßID, tblAdressenAnw.OrtID, tblAdressenAnw.GebDatum,
tblAdressenAnw.AnrBriefkopf, tblAdressenAnw.[Telefon 1],
tblAdressenAnw.Bemerkungen
FROM tblAdressenAnw
WHERE (((tblAdressenAnw.Nachname) Like "*" & [Filter: Name/Bezeichnung
oder frei lassen:] & "*") AND ((tblAdressenAnw.OrtID) Like "*" &
[Filter: PLZ und/oder Ort oder freilassen:] & "*"))

ORDER BY tblAdressen.Nachname;

Alle 3 Tabellen sind vorhanden und lassen sich einzeln öffnen. Wenn
ich den 2. oder 3. UNION SELECT-Teil lösche, funktioniert sie auch.
Aller Felder sind vorhanden. Die Tabelle tblAdressen findet sich
jedoch in einer anderen Backend (.accdb) wie tblAdressenAnw und
tblAdressenDiv.

Hat jemand was beizusteuern???

Grüße und Dank
Sebastian

[André Minhorst]

Hallo Sebastian,

Am Fri, 16 May 2008 12:01:18 -0700 (PDT) schrieb Sebastian Brandt:
> Habe ein Problem mit folgender Abfrage (SQL-Ansicht):
>
> SELECT tblAdressen.AdrNr, tblAdressen.Nachname, tblAdressen.Vorname,

> [...]

>
> Alle 3 Tabellen sind vorhanden und lassen sich einzeln öffnen. Wenn
> ich den 2. oder 3. UNION SELECT-Teil lösche, funktioniert sie auch.
> Aller Felder sind vorhanden. Die Tabelle tblAdressen findet sich
> jedoch in einer anderen Backend (.accdb) wie tblAdressenAnw und
> tblAdressenDiv.

wie äußert sich denn das Scheitern?

Kommt ein Fehler, gibt die Abfrage keine Datensätze aus?

Ciao
André

--
http://www.access-entwicklerbuch.de
http://www.access-im-unternehmen.de

[Sebastian Brandt]

Hallo Andre,

> wie äußert sich denn das Scheitern?
>
> Kommt ein Fehler, gibt die Abfrage keine Datensätze aus?

Beides: Fehlermeldung und Abfrage wird nicht angezeigt...
>
Grüße Sebastian

[André Minhorst]

Komm, Sebastian,

Am Fri, 16 May 2008 12:27:24 -0700 (PDT) schrieb Sebastian Brandt:

>> wie äußert sich denn das Scheitern?
>>
>> Kommt ein Fehler, gibt die Abfrage keine Datensätze aus?
> Beides: Fehlermeldung und Abfrage wird nicht angezeigt...

lass Dir nicht alles einzeln aus der Nase ziehen. Welche Fehlermeldung gibt
es?

Wenn Du die Anfrage in der SQL-Ansicht ausführst, welche Stelle wird nach
der Fehlermeldung markiert?

[Sebastian Brandt]

Hallo Andre,

sorry, musste kurz außer Haus...

> >> Kommt ein Fehler, gibt die Abfrage keine Datensätze aus?
> > Beides: Fehlermeldung und Abfrage wird nicht angezeigt...
>
> lass Dir nicht alles einzeln aus der Nase ziehen. Welche Fehlermeldung gibt es?

Entschuldige, wie im Betreff beschrieben: »Das Microsoft Office Access-
Datenbankmodul konnte das Objekt '' nicht finden. Stellen Sie sicher,
dass das Objekt vorhanden ist und dass die Namens- und Pfadangaben
richtig eingegeben wurden.«

> Wenn Du die Anfrage in der SQL-Ansicht ausführst, welche Stelle wird nach
> der Fehlermeldung markiert?

Cursor steht ganz am Ende

Ich danke Dir
Sebastian

[André Minhorst]

Hallo Sebastian,

Am Fri, 16 May 2008 14:21:58 -0700 (PDT) schrieb Sebastian Brandt:
>>>> Kommt ein Fehler, gibt die Abfrage keine Datensätze aus?
>>> Beides: Fehlermeldung und Abfrage wird nicht angezeigt...
>>
>> lass Dir nicht alles einzeln aus der Nase ziehen. Welche Fehlermeldung gibt es?
> Entschuldige, wie im Betreff beschrieben: »Das Microsoft Office Access-
> Datenbankmodul konnte das Objekt '' nicht finden. Stellen Sie sicher,
> dass das Objekt vorhanden ist und dass die Namens- und Pfadangaben
> richtig eingegeben wurden.«
>
>> Wenn Du die Anfrage in der SQL-Ansicht ausführst, welche Stelle wird nach
>> der Fehlermeldung markiert?
> Cursor steht ganz am Ende

funktionieren denn alle Abfragen einzeln ohne Probleme?

[Sebastian Brandt]

Hallo Andre,

> funktionieren denn alle Abfragen einzeln ohne Probleme?

ja einzeln und auch zu weit, aber nicht alle 3 zusammen???

Grüße Sebastian

[Karl Donaubauer]

> ...

Hmm, vielleicht spielt letzteres ja wirklich eine Rolle.
Hast du schon überprüft, ob's am ORDER BY liegt?
Also mal die letzte Zeile komplett weggelassen?

Wenn's das sein sollte, dann versuch's mit:

ORDER BY 2

--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com
+ Entwickler-Konferenzen für Access und SQL Server

[Sascha Trowitzsch]

Hi,

"Karl Donaubauer" <NoS...@donkarl.com> schrieb im Newsbeitrag
news:697oq4F...@mid.individual.net...

Oder die ganzen UNIONs einklammern und dahinter das ORDER BY Nachname - ohne
tblAdressen!
So, wie's hingeschrieben steht, bezieht sich das ORDER BY ja auf die letzte
UNION.Abfrage, die diese Tabelle nicht kennt.

Ciao, Sascha

[Sebastian Brandt]

Hallo Karl,

>
> Hmm, vielleicht spielt letzteres ja wirklich eine Rolle.
> Hast du schon überprüft, ob's am ORDER BY liegt?
> Also mal die letzte Zeile komplett weggelassen?
>
> Wenn's das sein sollte, dann versuch's mit:
>
> ORDER BY 2

Am ORDER liegt es nicht...

Grüße und Dank
Sebastian

[Jörg Ackermann]

Hallo,

Sebastian Brandt meinte:

> Am ORDER liegt es nicht...

Vielleicht hängt das ja auch mit Deinem anderen
Problem zusammen:

> Auf verknüpfter Tabelle basierende Abfrage kann ich öffnen, die Tabelle jedoch nicht

Versuche mal, die Tabellen direkt anzusprechen:

SELECT tblAdressen....
FROM tblAdressen IN 'C:\WASWEISSICH\backend1.mdb'
WHERE ...

UNION SELECT tblAdressenDiv....
FROM tblAdressenDiv IN 'C:\WASWEISSICH\backend2.mdb'
WHERE ...

usw.

Gruß

[Ekkehard Böhme]

Hallo Sebastian,

Ja, denke über Dein Datenmodell nach (Stichwort: Normalisierung).

Wie das aussieht hast Du doch drei Tabellen mit identischen Feldern. Ich
nehme deshalb an, dass sich die Adressen, die in den einzelnen Tabellen
stehen irgendein Kriterium (...Div, ...Anw) erfüllen, das sie von den
anderen unterscheidet. Das kannst Du aber viel einfacher mit einem
zusätzlichen Feld in /einer/ Tabelle haben.
Da gehst Du dann den anderen Weg; - wenn Du nur die Adressen brauchst
die z.B. in tblAdressenAnw stehen filterst Du die aus der Gesamttabelle
(jetzt dein UNION), und gut ist.

>
> Grüße und Dank
> Sebastian

gruss ekkehard

[André Minhorst]

Hallo Ekkehard,

Am Sat, 17 May 2008 17:59:54 +0200 schrieb Ekkehard Böhme:

> Ja, denke über Dein Datenmodell nach (Stichwort: Normalisierung).
>
> Wie das aussieht hast Du doch drei Tabellen mit identischen Feldern. Ich
> nehme deshalb an, dass sich die Adressen, die in den einzelnen Tabellen
> stehen irgendein Kriterium (...Div, ...Anw) erfüllen, das sie von den
> anderen unterscheidet. Das kannst Du aber viel einfacher mit einem
> zusätzlichen Feld in /einer/ Tabelle haben.
> Da gehst Du dann den anderen Weg; - wenn Du nur die Adressen brauchst
> die z.B. in tblAdressenAnw stehen filterst Du die aus der Gesamttabelle
> (jetzt dein UNION), und gut ist.

Sebastian bezieht die Daten aus verschiedenen Datenbanken. Da ist nichts
mit Normalisieren ...

[Karl Donaubauer]

Sascha Trowitzsch wrote:
> "Karl Donaubauer schrieb:

>> Sebastian Brandt wrote:
>>> Habe ein Problem mit folgender Abfrage (SQL-Ansicht):
>>>
>>> SELECT tblAdressen.AdrNr, tblAdressen.Nachname, tblAdressen.Vorname,

>>> ...
>>> UNION SELECT tblAdressenAnw.AdrNr, tblAdressenAnw.Nachname,
>>> ...

>>> ORDER BY tblAdressen.Nachname;
>>>
>>> Alle 3 Tabellen sind vorhanden und lassen sich einzeln öffnen. Wenn
>>> ich den 2. oder 3. UNION SELECT-Teil lösche, funktioniert sie auch.
>>> Aller Felder sind vorhanden. Die Tabelle tblAdressen findet sich
>>> jedoch in einer anderen Backend (.accdb) wie tblAdressenAnw und
>>> tblAdressenDiv.
>>> ...
>> Hmm, vielleicht spielt letzteres ja wirklich eine Rolle.
>> Hast du schon überprüft, ob's am ORDER BY liegt?
>> Also mal die letzte Zeile komplett weggelassen?
>>
>> Wenn's das sein sollte, dann versuch's mit:
>>
>> ORDER BY 2
>
> Oder die ganzen UNIONs einklammern und dahinter das ORDER BY Nachname -
> ohne tblAdressen!
> So, wie's hingeschrieben steht, bezieht sich das ORDER BY ja auf die
> letzte UNION.Abfrage, die diese Tabelle nicht kennt.

Naa, so wie er es verwendet, ist es an sich syntaktisch ok.
Das ORDER BY in einer UNION muss am Ende stehen und sich
auf einen Feldnamen des _ersten_ UNION-Teiles beziehen
(bzw. wird von JET darauf bezogen). Andernfalls gibt's eine
entsprechende, aussagekräftige Fehlermeldung. Der
Tabellenname ist dabei nicht nötig, stört aber auch nicht.

Ich wollte mit dem Einwurf nur ausschließen, dass es etwas
mit den unterschiedlichen DBs zu tun haben kann.

--
cu

[Ekkehard Böhme]

Hallo André,

> Hallo Ekkehard,
>
> Am Sat, 17 May 2008 17:59:54 +0200 schrieb Ekkehard Böhme:
>
>> Ja, denke über Dein Datenmodell nach (Stichwort: Normalisierung).
>>
>> Wie das aussieht hast Du doch drei Tabellen mit identischen Feldern. Ich
>> nehme deshalb an, dass sich die Adressen, die in den einzelnen Tabellen
>> stehen irgendein Kriterium (...Div, ...Anw) erfüllen, das sie von den
>> anderen unterscheidet. Das kannst Du aber viel einfacher mit einem
>> zusätzlichen Feld in /einer/ Tabelle haben.
>> Da gehst Du dann den anderen Weg; - wenn Du nur die Adressen brauchst
>> die z.B. in tblAdressenAnw stehen filterst Du die aus der Gesamttabelle
>> (jetzt dein UNION), und gut ist.
>
> Sebastian bezieht die Daten aus verschiedenen Datenbanken. Da ist nichts
> mit Normalisieren ...

O.K., hab' ich überlesen. Fragt sich wo da der Sinn liegt, und ob es da
nicht doch am Datenmodell was zu verbessern gibt.

>
> Ciao
> André
>
gruss ekkehard

[Sebastian Brandt]

Hallo Ekkehard, hallo Andre, hallo Karl,

> Sebastian bezieht die Daten aus verschiedenen Datenbanken. Da ist nichts
> mit Normalisieren ...

Der Grund der verschiedenen Datenbanken: Eine enthält die Adressen des
Anwenders (1. Backend), die anderen beiden Tabellen (2. Backend)
Adressen, welche von mir gepflegt werden...

Vielleicht von Bedeutung? Die Abfrage wurde ursprünglich unter Acc97
erstellt, wo sie definitiv reibungslos lief. Das Problem ist erst
später aufgetaucht. Es lässt sich aber nicht mehr genau klären seit
wann (Portierung nach Acc2000 und jetzt Acc2007)...

Mit den Klammern experimentiere ich noch, bekomme dabei nun folgende
Fehlermeldung:

Syntaxfehler in Abfrageausdruck '(((tblAdressen.Nachname) Like "*" &

[Filter: Name/Bezeichnung oder frei lassen:] & "*") AND
((tblAdressen.OrtID) Like "*" & [Filter: PLZ und/oder Ort oder
freilassen:] & "*"))

(UNION SELECT tblAdressenDiv.AdrNr, tblAdressenDiv.Nachname,
tblAdressenDiv.'.
Der angezeigt Ausdruck ist ca. 256 Zeichen lang. Mir scheint das
maximal 256 Zeichen zwischen Klammern erlaubt sind???

Grüße Sebastian

[Sebastian Brandt]

Hallo Jörg,

> Vielleicht hängt das ja auch mit Deinem anderen
> Problem zusammen:
> Auf verknüpfter Tabelle basierende Abfrage kann ich öffnen, die Tabelle jedoch nicht

Nein, das funktioniert an meinem Rechner ja alles ohne Probleme...

>
> Versuche mal, die Tabellen direkt anzusprechen:
>

das habe ich getan mit nur 2 Tabellen (was vorher ging):

SELECT tblAdressen.AdrNr, tblAdressen.Nachname, tblAdressen.Vorname,
tblAdressen.AKzID, tblAdressen.SozID, tblAdressen.StrßID,
tblAdressen.OrtID, tblAdressen.GebDatum, tblAdressen.AnrBriefkopf,
tblAdressen.[Telefon 1], tblAdressen.Bemerkungen

FROM tblAdressen IN 'Q:\AKV\Db\AKVDatUsr.accdb'

WHERE (((tblAdressen.Nachname) Like "*" & [Filter: Name/Bezeichnung
oder frei lassen:] & "*") AND ((tblAdressen.OrtID) Like "*" & [Filter:
PLZ und/oder Ort oder freilassen:] & "*"))

UNION SELECT tblAdressenDiv.AdrNr, tblAdressenDiv.Nachname,
tblAdressenDiv.Vorname, tblAdressenDiv.AKzID, tblAdressenDiv.SozID,
tblAdressenDiv.StrßID, tblAdressenDiv.OrtID, tblAdressenDiv.GebDatum,
tblAdressenDiv.AnrBriefkopf, tblAdressenDiv.[Telefon 1],
tblAdressenDiv.Bemerkungen

FROM tblAdressenDiv IN 'Q:\AKV\Db\AKVDatExt.accdb'

WHERE (((tblAdressenDiv.Nachname) Like "*" & [Filter: Name/Bezeichnung
oder frei lassen:] & "*") AND ((tblAdressenDiv.OrtID) Like "*" &
[Filter: PLZ und/oder Ort oder freilassen:] & "*"))

und bekam folgende neue Fehlermeldung:
»Ein Verweis auf eine Tabelle mit einem mehrwertigen Feld ist nicht
möglich, wenn das Feld eine IN-Klausel verwendet, die auf eine andere
Datenbank verweist.«

Ich verwende aber kein mehrwertiges Feld???

Grüße Sebastian

[Sebastian Brandt]

Hallo,

> > Sebastian bezieht die Daten aus verschiedenen Datenbanken. Da ist nichts
> > mit Normalisieren ...
>
> O.K., hab' ich überlesen. Fragt sich wo da der Sinn liegt, und ob es da
> nicht doch am Datenmodell was zu verbessern gibt.

Ich könnte maximal die beiden Adressebestände ...Anw und ...Div in
eine Tabelle umschichten. Problem für mich aber, dass der Index
(AdrNr) dann nicht mehr eindeutig wäre. Aus beiden (externen) Tabellen
(...Anw und ...Div ) - welche ich selbst aus unterschiedlichen
Datenquellen generiere - können Adressen in die interne Tabelle
dupliziert und geändert werden. Diese bleiben über einen Index (AdrNr)
verknüpft und werden bei Unstimmigkeiten nach einem Update ggf.
synchronisiert.

Wenns aber gar nicht anders geht, müsste ich dies wohl doch mal in
Erwägung ziehen. Nochmals als Anmerkung: unter Acc97 ging es
definitiv???

Grüße Sebastian

[Sebastian Brandt]

Ein spätes Hallo nochmal,

habe das Problem so gelöst, daß ich eine UNION SELECT Abfrage für die
beiden externen Bestände erstellt habe und diese Abfrage dann mi der 3.
Tabelle mittels neuer UNION SELECT Abfrage nun gemeinsam öffnen kann...

Grüße Sebastian