SQL abfrage an ACCESS macht probleme

[Ole]

hi

ich habe ein ACCESS datenbank mit einer tabelle names "auftrag" dort gibt es u.a. die felder "eigner", "kunde" und "user"

in "eigner" und "kunde" steht jeweils nur eine ID, das "user" feld ist eine durch komma getrennte liste.

nun will ich die aufträge aus der liste suchen bei denen der kunde (68) oder eine eigner_id (59) dem feld "eigner" entsprechen und der kunde (68) entweder "kunde" oder "user" ist.

im klartext:

eigner soll gleich 68 oder 59 sein

und

kunde oder user sollen 68 sein bzw. enthalten

meine SQL abfrage sieht daher folgendermaßen aus:

SELECT * FROM auftrag
WHERE eigner='59' Or eigner='68' and
(
kunde='68' Or user Like '68,%' Or user Like '%,68,%' Or user like '%,68'
)

doch irgenwo steckt da der wurm drin, denn ich bekomme grundsätzlich alle auftraege ausgegeben bei denen der eigner 59 ist. kein wunder hab ich mir gedacht, die erste OR anweisung macht mein vorhaben ja auch zu nichte...also hab ich das ganze etwas umngestrickt:

SELECT * FROM auftrag
WHERE
(
eigner='59' Or eigner='68'
)
and
(
kunde='68' Or user Like '68,%' Or user Like '%,68,%' Or user like '%,68'
)

jetzt bekomm ich allerdings keine ergebnisse, obwohl ich mind. einen datensatz habe bei dem "eigner" 59 ist und "user" die 68 enthält. :(

wo ist mein denkfehler?

thx
alles liebe
ole
(8-)>

[dey]

Servus

Versuch mal mein Beispiel auf Dein Problem umzulegen. So funktioniert es mit meiner Tabelle!

SELECT DISTINCT [ENVIRONMENT:PEN].PENPTN, [ENVIRONMENT:PEN].PENNZT, [ENVIRONMENT:PEN].PENNMA, [ENVIRONMENT:PEN].PENNMI
FROM [ENVIRONMENT:PEN]
WHERE ((([ENVIRONMENT:PEN].PENNZT)="l") AND (([ENVIRONMENT:PEN].PENNMA)=3.7)) OR ((([ENVIRONMENT:PEN].PENNZT)="l") AND (([ENVIRONMENT:PEN].PENNMA)=2.5));

Tip:
Im Access kann sehr schön SQL konstruieren lassen. Einfach eine Abfrage klassisch in der Entwurfsansicht erzeugen und dann mit [Ansicht | SQL] nach SQL konvertieren.
Ist SQL für Dummies. Mach ich immer so wenns klemmt. Hab ich hier auch gemacht!!!!

bydey

[Ole]

hi dey

ich sitze hier jetzt schon eine geschlagene stunde und quäle mich durch die abfragen erstellung in access. ich muß allerdings sagen, das der wizard und das ganze zusammengeclcike mir keine große hilfe sind, da der produzierten sql-code alles andere als lesbar ist.
außerdem versteh ich das teil nciht so ganz, da ist mir die manuelle sql-code-erzeugung um welten lieber.

mein sql buch ist mir auch keine große hilfe, da steht nichtmal like drin *grummel*

so long
ole
(8-)>

[dey]

Servus Ole

ich sitze hier jetzt schon eine geschlagene stunde und quäle mich durch die abfragen erstellung in access. ich muß allerdings sagen, das der wizard und das ganze zusammengeclcike mir keine große hilfe sind, da der produzierten sql-code alles andere als lesbar ist.
außerdem versteh ich das teil nciht so ganz, da ist mir die manuelle sql-code-erzeugung um welten lieber.

deine Einstellung ist einfach falsch, denn siehe da Du hast in einer h keine Lösung zustande gebracht und meine läuft nach 5 min!
Es fehlt meiner vielleicht an Eleganz, da diese im Quelltext aber IMHO nicht so wichtig ist stört es mich nicht.
Die Lösung lautete falls Du es nicht gesehen haben solltest:
where 1=1 and 2=2 or 3=3 and 2=2

ohne Klammern!
Ergo den Kontext nach dem and musst Du in jedes or übernehmen. Sagt zumindest ACCESS-SQL-Konverter.

mein sql buch ist mir auch keine große hilfe, da steht nichtmal like drin *grummel*

so long
ole
(8-)>

bydey

[Ole]

hi

es ist montag morgen, was erwartest du von mir? ;)

die lösung ist so einfach wie ärgerlich:

ACCESS akzeptiert % nicht als Wildcard, sondern nimmt *

ich denke ich werd das ganze zu MySql umstricken, da kann ich mich wenigstens an die gängige SQL-Syntax halten *grummel*.

dank euch beiden
so long
ole
(8-)>

ps: mein buch werde ich im laufe des tages noch verbrennen, auch wenns von Addison-Wesley ist und mich 50 Eur gekostet hat *grrr*

[susanne]

Jetzt musst Du Deine Signatur wohl abändern:
aber: Self-Forum macht kluch? - reimt sich nicht!
Schwierig, schwierig...
Gruß
Susanne

ps: mein buch werde ich im laufe des tages noch verbrennen, auch wenns von Addison-Wesley ist und mich 50 Eur gekostet hat *grrr*

[Ole]

hi susanne

Jetzt musst Du Deine Signatur wohl abändern:
aber: Self-Forum macht kluch? - reimt sich nicht!
Schwierig, schwierig...

hmmm...naja genaugenommen hab ich die lösung ja auch nicht aus dem Self-Raum, sondern von einem befreundeten programmierer, den ich aus dem Bett geklingelt habe (er ist nachtaktiv und daher erst vor ca 2 stunden ins bett gekommen *g*).

aber das mit dem reimen ist echt ein sehr schwieriges unterfangen *grübel*.

alles liebe
ole
(8-)>

[susanne]

Hallo,
warum benutzt du in Deinem Querie LIKE und nicht = (equal)? Denn Du willst doch nach = abfragen und bei Zahlen macht LIKE sowieso selten Sinn. Außerdem scheint mir die Syntax für LIKE falsch zu sein (warum Kommas?).
Gruß
Susanne

hi

ich habe ein ACCESS datenbank mit einer tabelle names "auftrag" dort gibt es u.a. die felder "eigner", "kunde" und "user"

in "eigner" und "kunde" steht jeweils nur eine ID, das "user" feld ist eine durch komma getrennte liste.

nun will ich die aufträge aus der liste suchen bei denen der kunde (68) oder eine eigner_id (59) dem feld "eigner" entsprechen und der kunde (68) entweder "kunde" oder "user" ist.

SELECT * FROM auftrag
WHERE
(
eigner='59' Or eigner='68'
)
and
(
kunde='68' Or user Like '68,%' Or user Like '%,68,%' Or user like '%,68'
)

[Ole]

hi Susanne

die felder "eigner" "kunde" und "user" enthalten strings und keine zahlen (hätte ich vieleicht vorher erwähnen sollen :)), daher LIKE

die kommas in der LIKE bedingung stammen daher, das die einzelnen IDs durch komma getrennt da drin stehen a la "58,59,60,61", da es allerding irgendwann auch werte wie 168 1684 etc, geben wird muß ich auch nach den kommas suchen.

alles liebe
ole
(8-)>

[Frank aus Ulm]

Hi, hallo

die felder "eigner" "kunde" und "user" enthalten strings und keine zahlen (hätte ich vieleicht vorher erwähnen sollen :)), daher LIKE

alle 3?? dann solltest du dir evt. mal überlegen dein Datenmodell etwas zu optimieren, LIKE ist einer der unperformantesten Operatoren mit exponentiellem Performanceverlust bei steigender Tabellengröße.

168 und 1684 ....

wobei würde dein (mögliches) like "68,%" anschlagen?

[ ] "1,168,244"
[ ] "1,68,244"
[ ] "68,1,244"

und wobei soll es anschlagen?

[ ] "1,168,244"
[ ] "1,68,244"
[ ] "68,1,244"

schon allein aus diesem Grunde eignet sich Like eher minder. Versuch es doch über eine transponierte Tabelle und dem SQL "WHERE x in (....)"

[tab1]
order  dataTyp      dataID
1      eigner       1
1      eigner       68
1      user         68
1      user         169
1      user         170
1      kunde        2

Beispiel: SELECT *  From tab1 WHERE (dataTyp='eigner' or dataTyp='user') AND dataID in (1,68,170)

die Tabelle wird dann zwar etwas länger, aber dafür performanter da kein LIKE (*grrrrrrrrrr*) mehr verwendet werden muß

Tschau, tschüß,
Frank

[Ole]

hi Frank

alle 3?? dann solltest du dir evt. mal überlegen dein Datenmodell etwas zu optimieren, LIKE ist einer der unperformantesten Operatoren mit exponentiellem Performanceverlust bei steigender Tabellengröße.

wenn alles so weiter läuft wird das ganze eh von access auf MySql umgestellt und dann kann man auch anständiges SQl verwenden :)

wobei würde dein (mögliches) like "68,%" anschlagen?

[ ] "1,168,244"
[ ] "1,68,244"
[x] "68,1,244"

da  das "%" anzeigt, das nur nach  "68," eine beliebige anzahl an zeichen steht, wird nur der dritte datensatz ausgegeben :)

und wobei soll es anschlagen?

[ ] "1,168,244"
[ ] "1,68,244"
[x] "68,1,244"

s.o.

schon allein aus diesem Grunde eignet sich Like eher minder. Versuch es doch über eine transponierte Tabelle und dem SQL "WHERE x in (....)"

ist ne überlegung wert den vorschlag in die neue datenbank einfließen zu lassen :)

so long
ole
(8-)>

[Frank aus Ulm]

Hi, hallo nochmals

und wobei soll es anschlagen?

[ ] "1,168,244"
[ ] "1,68,244"
[x] "68,1,244"

warum nur bei drittens, bei zweitens:

[ ] "1,68,244"

ist doch auch ID 68 drin, ich dachte ja gerade du willst so selektieren, daß du alle Datensätze erhältst, die mit User-ID 68 in Verbindung stehen...

LIKE ist bei MySQL wie Access wie jedem anderen DBMS genauso sinnig = unperformant... SQL ist kein Wunderheilmittel für suboptimales Datenmodelling, wenn du verstehst.

Aber schön, daß dir mein Vorschlag mit der anderen Tabellenform gefällt, unterstüzt MySQL denn den Operator "IN"?

Tschau, tschüß,
Frank

[Ole]

hi frank

deine frage war folgende:

"wobei würde dein (mögliches) like "68,%" anschlagen?"

warum nur bei drittens, bei zweitens:

[ ] "1,68,244"

ist doch auch ID 68 drin, ich dachte ja gerade du willst so selektieren, daß du alle Datensätze erhältst, die mit User-ID 68 in Verbindung stehen...

klar will ich das, allerdings bekomme ich mit dieser LIKE anweisung nur die datensätze ausgegeben bei denen "68," am anfang steht.

mit "%,68" würde ich nur die bekommen die am ende stehen und mit "%,68,%" bekomme ich die bei denen das ganze mittendrin steht.

LIKE ist bei MySQL wie Access wie jedem anderen DBMS genauso sinnig = unperformant... SQL ist kein Wunderheilmittel für suboptimales Datenmodelling, wenn du verstehst.

das problem ist das das ganze ziemlich organisch gewachsen ist und eigentlich nur eine ganz kleine anwendung sein sollte, zu demozwecken, die allerdings mittlerweile so guten anklang findet, das sie wächst und wächst und ich in der aktuellen version keine zeit/möglichkeit für eine DB-redesign habe.

Aber schön, daß dir mein Vorschlag mit der anderen Tabellenform gefällt, unterstüzt MySQL denn den Operator "IN"?

afaik tut es das :)

so long
ole
(8-)>