Access97: NEAR-Statement

Hallo!

Wie kann ich denn bei folgendem Query noch ein NEAR-Statement einbauen? Leider habe ich gerade mein SQL-Buch nicht.

Ich habe zwei Tabellen:

tblESN
Accountname | Country | …

tblPartner
Company | Country | …

Query:
SELECT tblESN.Accountname, tblESN.Country, tblPartner.Company, tblPartner.Country
FROM tblESN, tblPartner
WHERE (((tblESN.Accountname)=[tblPartner]![Company]) AND ((tblESN.Country)=[tblPartner]![Country]))
ORDER BY tblPartner.Country;

Ich moechte, dass der Query alle Accountnamen aus tblESN auflistet, die dem Text in „Company“ aehnlich sind. Bis jetzt werden nur diejenigen angezeigt, die genau gleich geschrieben wurden.

Tanja

Hallo!

Wie kann ich denn bei folgendem Query
noch ein NEAR-Statement einbauen? Leider
habe ich gerade mein SQL-Buch nicht.

Hi,
zunächst mal: Egal, was Du in dieser Hinsicht anstellst, wird sich negativ auf die Performance auswirken, da evtl. vorhandene Indizes für die Abfrage nicht verwendet werden können.

Es gibt zwar einen Operator LIKE, aber der wird wahrscheinlich hier nicht weiterhelfen, da LIKE Jokerzeichen braucht (LIKE ‚*TEST*‘ holt alle Datensätze wie ‚ATTEST‘, ‚TESTAT‘, ‚TEST‘, usw.), aber wo würdest Du sie einsetzen?

Ansonsten mußt Du definieren, was für Deine Zwecke „ähnlich“ heißt. Ich würde es in eine Funktion packen, sagen wir Normiere(), die aus einem beliebigen Eingangsstring einen „normierten“ zurückgibt, z.B. durch Unterdrücken von Sonderzeichen, Ersetzen von ‚ß‘ durch ‚ss‘, usw.

Dann würde ich die Abfrage so formulieren, daß sie nicht die Werte direkt vergleicht, sondern das Ergebnis meiner Funktion:

SELECT tblESN.Accountname,
tblESN.Country, tblPartner.Company,
tblPartner.Country
FROM tblESN, tblPartner
WHERE
Normiere(tblESN.Accountname)=Normiere(tblPartner.Company)
AND
tblESN.Country=tblPartner.Country
ORDER BY tblPartner.Country;

Gruß
J.

Jet-SQL kennt kein „NEAR“… Eine Suche mit LIKE und „*“ am Ende ist nicht ineffizienter als ein entsprechender Vergleich mit BETWEEN bzw. „>“ und "

Hallo Reinhard!

Wenn ich den Query jetzt mit LIKE mache, kommt kein Datensatz als Ergebnis raus:

SELECT tblESN.Accountname, tblESN.Country, tblPartner.Company, tblPartner.Country
FROM tblESN, tblPartner
WHERE (((tblESN.Accountname) LIKE „*[tblPartner]![Company]*“) AND ((tblESN.Country)=[tblPartner]![Country]))
ORDER BY tblPartner.Country;

Was habe ich falsch gemacht? Es muessten doch zumindest auch die 50 Datensaetze rauskommen, die ich bekomme, wenn ich die Abfrage mit „=“ anstatt mit „LIKE“ mache.

Tanja

Hallo!

zunächst mal: Egal, was Du in dieser
Hinsicht anstellst, wird sich negativ auf
die Performance auswirken, da evtl.
vorhandene Indizes für die Abfrage nicht
verwendet werden können.

Die Performance ist total egal. Ich muss einfach mal herausfinden, welche Unternehmen sowohl auf der ESN- und auf der Partner-Liste stehen. Es waren eigentlich zwei Excel-Listen mit je 1.700 und 300 Datensaetzen, die ich in Access konvertiert habe, da ich dachte, dass es damit besser ginge als mit Excel.

Es gibt zwar einen Operator LIKE, aber
der wird wahrscheinlich hier nicht
weiterhelfen, da LIKE Jokerzeichen
braucht (LIKE ‚*TEST*‘ holt alle
Datensätze wie ‚ATTEST‘, ‚TESTAT‘,
‚TEST‘, usw.), aber wo würdest Du sie
einsetzen?

… WHERE (((tblESN.Accountname) LIKE „*[tblPartner]![Company]*“)…
So muesste man „Beispiel GmbH“ doch auch finden, wenn in tblPartner nur „Beispiel“ stehen wuerde. Aber irgendwie funktioniert es nicht, Access findet jetzt gar keinen Datensatz mehr, anstatt der 50, die ich mit „=“ anstatt „LIKE“ finde.

Ansonsten mußt Du definieren, was für
Deine Zwecke „ähnlich“ heißt. Ich würde
es in eine Funktion packen, sagen wir
Normiere(), die aus einem beliebigen
Eingangsstring einen „normierten“
zurückgibt, z.B. durch Unterdrücken von
Sonderzeichen, Ersetzen von ‚ß‘ durch
‚ss‘, usw.

In beiden Tabellen gibt es keine Sonderzeichen und Umlaute, die Firmennamen unterscheiden sich nur dadurch, dass in einer manchmal nur Teilstrings der anderen stehen.

Tanja

Hallo Reinhard!

Wenn ich den Query jetzt mit LIKE mache,
kommt kein Datensatz als Ergebnis raus:

SELECT tblESN.Accountname,
tblESN.Country, tblPartner.Company,
tblPartner.Country
FROM tblESN, tblPartner
WHERE (((tblESN.Accountname) LIKE
„*[tblPartner]![Company]*“) AND
((tblESN.Country)=[tblPartner]![Country]))
ORDER BY tblPartner.Country;

Mit LIKE machst Du ja einen Strigvergleich.
So formuliert, fragst Du nach allen Datensätzen, die den Inhalt ähnlich „[tblPartner]![Company]“ haben.
Stattdessen mußt Du

SELECT tblESN.Accountname,
tblESN.Country, tblPartner.Company,
tblPartner.Country
FROM tblESN, tblPartner
WHERE (((tblESN.Accountname) LIKE
„*“ & [tblPartner]![Company] & „*“) AND
((tblESN.Country)=[tblPartner]![Country]))
ORDER BY tblPartner.Country;

angeben.
Gruß
J.

Das wird so vermutlich überhaupt nichts (ich bezweifle, dass Josés SQL funktioniert, da die String-Verkettung in SQL-Vergleichsausdrücken nur begrenzt einsetzbar ist).

Vermutlich musst du einen komplett anderen Ansatz wählen (also z.B. erst in einer Abfrage die Datensätze mit LIKE auswählen und dann den JOIN darüber machen).

Reinhard

Das wird so vermutlich überhaupt nichts
(ich bezweifle, dass Josés SQL
funktioniert, da die String-Verkettung in
SQL-Vergleichsausdrücken nur begrenzt
einsetzbar ist).

Hi!
Das ist zwar verwunderlich, aber es funktioniert doch!
Diesen Vorschlag hatte ich ausnahmsweise ausprobiert :smile: , da es mir auch seltsam vorkam.
Gruß
J.

Hallo ihr zwei!

Das ist zwar verwunderlich, aber es
funktioniert doch!

Es funktioniert wunderbar, er findet jetzt mit LIKE 63 Datensaetze anstatt 50 mit „=“.

Eigentlich moechte ich aber die Partner haben, die nicht in der ESN-Liste stehen. Es muesste also

SELECT tblPartner.Company, tblPartnerCountry
FROM tblPartner
WHERE tblPartner.Company
NOT IN (SELECT qryPartnerInESN.Company FROM qryPartnerInESN);

heissen oder so aehnlich… Wie lautet denn jetzt die richtige Syntax in Jet-SQL? So funktioniert es mal wieder nicht! Oder waere es besser beides in der ersten Abfrage durchzufuehren?

Gruesse, Tanja

Hallo ihr zwei!

Hallo!

Eigentlich moechte ich aber die Partner
haben, die nicht in der ESN-Liste stehen.

Puhhh!

SELECT tblPartner.Company,
tblPartnerCountry
FROM tblPartner
WHERE tblPartner.Company
NOT IN (SELECT qryPartnerInESN.Company
FROM qryPartnerInESN);

Wie lautet
denn jetzt die richtige Syntax in
Jet-SQL?

An der Syntax scheint mir alles in Ordnung…
Aber solltest Du Dich nicht im Subselect auf die Spalte Accountname beziehen? Das sind doch die unterschiedlichen 63, von den Companys gibt es nur 50…

Aber Du hast recht: Warum nicht gleich in der ersten Abfrage LIKE durch NOT LIKE ersetzen?

Das probiere ich aber jetzt nicht mehr aus!

Gruß

J.

Hallo!

Eigentlich moechte ich aber die Partner
haben, die nicht in der ESN-Liste stehen.

Puhhh!

SELECT tblPartner.Company,
tblPartnerCountry
FROM tblPartner
WHERE tblPartner.Company
NOT IN (SELECT qryPartnerInESN.Company
FROM qryPartnerInESN);

Wie lautet
denn jetzt die richtige Syntax in
Jet-SQL?

An der Syntax scheint mir alles in
Ordnung…

Wenn ich das so schreibe, stuerzt Access immer ab, in der Statuszeile steht „Recordset not updatable.“

Aber solltest Du Dich nicht im Subselect
auf die Spalte Accountname beziehen? Das
sind doch die unterschiedlichen 63, von
den Companys gibt es nur 50…

Nein, das stimmt schon. Es gibt 1700 Accountnamen und 300 Partner, ich will jetzt wissen, welche der 300 Partner nicht in der ESN-Liste stehen.

Durch stichprobenartiges Ueberpruefen habe ich herausgefunden, dass irgendwas an meinen Queries nicht stimmen kann:

SELECT DISTINCT tblPartner.Company, tblPartner.Country
FROM tblESN, tblPartner
WHERE (((tblPartner.Country)=[tblESN]![Country]) AND (("*" & [tblPartner]![Company] & „*“) NOT LIKE „*“ & [tblESN]![Accountname] & „*“))
ORDER BY tblPartner.Country;

In tblESN steht als Accountname „Datapoint Svenska AB“ und in tblPartner „Datapoint“. Wenn nich den Query mit LIKE ausfuehre, muesste die Firma eigentlich gefunden werden, was aber nicht der Fall ist. Stattdessen erscheint sie, wenn ich NOT LIKE schreibe! Wie kommt denn das nun schon wieder?

Langsam aber sicher glaube ich, dass ich es schneller hinbekomme, wenn ich es in Excel versuche, anstatt mich weiter mit Access rumzuaergern…

Gruesse, Tanja