Access-o-Mania

Hallo in die Runde,
bin heute darauf gestoßen dass beim Datentyp Double (wahrscheinlich auch ander Zahlentypen) ein Like in Hochkommatas stehen muss. Also z.B. Select * from tabelle where Zahlenfeld like '4711*'

Weiß jemand warum das so sein muss? Wegen dem Platzhalter etwa?
Gruß Andreas

Der Operator LIKE ist normalerweise für Textvergleiche vorgesehe. In Access wird bei einer LIKE-Abfrage angenommen, dass du einen Text suchst. Daher müssen die Werte, auch wenn sie Zahlen sind, in Anführungszeichen (oder Hochkommata) gesetzt werden, um als Text behandelt zu werden.

Holger

Hallo Hondo,

warum sollte man Zahlenvergleich mit einem Textvergleichsoperator wie "Like" machen wollen?
Insbesondere Vergleiche mit Double-Werten sind sowieso immer problematisch, da hier die binäre interne Darstellung immer mit beachtet werden muß und deshalb i.d.R. nicht auf Gleichheit geprüft werden kann. Hilfsweise kann mit >, < oder auf Gleichheit mit einem entsprechend ε geprüft werden.

Gruß
Ulrich

 

Da hat Ulli natürlich Recht. Das ganze macht keinen Sinn. Bei Zahlen immer nur mathematische Operatoren

Nenne mal ein Beispiel wo das bei dir Sinn macht.

Holger

Hallo,
in dem Ausdruck von Andreas ist ja noch ein Joker zu sehen.
.... where Zahlenfeld like '4711*'Offensichtlich sollen hier nur Teile einer Zahl (Double) verglichen werden. Und das geht nur wenn die Zahl als Text behandelt wird. Und dazu muss auch "Wie" (Like) verwendet werden. Daher sind hier die Hochkomma (oder Az ") zwingend erforderlich.

Es stellt sich aber trotzdem die Frage wozu das gut sein soll.
Wenn nur Teile der Zahl (bzw. Zeichenfolge) betrachtet bzw. verglichen werden sollen, warum legt man da nicht gleich ein Textfeld an ? Ein Zahlenfeld scheint mir da wenig sinnvoll.

Hallo,
ok dann hol ich mal weiter aus.
Im Zahlenfeld steckt ein Format: YYYYMMXXXX
Also Jahr, Monat und 4-stellig ein Zählfeld Null aufgefüllt.

Das Feld ist gleichzeitig ein Index.
Um neue Mitglieder anzulegen ohne diese Nummer zu kennen (kommt vom Verband) wird eine temporäre vergeben. Dazu wird das aktuelle Jahr und Monat genommen und geprüft ob es damit schon eine Zählnummer gibt.
Daher schreib ich diesen Monat ins Kriterium Like '202410*'

Ad hoc fällt mir keine andere Option ein um das zu prüfen.
Beim SQL-Server gäbe es ja dazu die Left() Funktion, aber bei Access?

Gruß Andreas

Hallo,
Left() gibt es auch bei Access.

Der Zähler gehört in ein extra Feld.
Über das Datum (das es auch geben sollte) kann in Abhängigkeit von Jahr und Monat der Zähler hochgezählt werden.

Wenn du bei deiner Version bleiben möchtest, solltest du aus dem Zahlenfeld ein Textfeld machen. Double macht hier ohnehin keinen Sinn, denn das kann niemals eine Kommazahl sein bzw. werden.

Hallo Andreas,

1. das Feld sollte als Textfeld angelegt werden und 2. könnte man den Zähler aus dem Feld in ein separates Feld herausziehen, dann wird daraus ein zusammengesetzter Key.

Wenn das ein Textfeld wäre, könnte man auf Platzhalter verzichten (Left()) und was den Zähler betrifft, mit Max() oder über Sort den nächsten "Zählerwert" bestimmen. Bei alphanumerischen Seriennummer wird das z.T. auch so gemacht.

Gruß
Ulrich

Zitat von: MzKlMu am Oktober 21, 2024, 09:50:22Der Zähler gehört in ein extra Feld.

geht nicht, weil 1. die Nummer vorgegeben wird vom Verband, 2. die Kombination Datum+Zähler ein Primärschlüssel darstellt.

Dass es left() in Access Abfragen gibt war mir bislang unbekannt, oder ich habs vergessen?
Hab das jetzt umgestellt, die Abfrage sieht jetzt z.B. so aus:

SELECT COUNT(msbnr) FROM tabmitglieder WHERE left(msbnr,6) = 202410

Achtung:

Count() geht nicht, es könnte ja mal ein DS gelöscht werden und dann funktioniert das nicht mehr. Immer die den Max() Wert ermitteln und den um 1 erhöhen.

Gruß Ulrich

Hallo,

Zitat2. die Kombination Datum+Zähler ein Primärschlüssel darstellt.

Das ist ja kein Datum, sondern nur Jahr und Monat. Solche Felder als PS sind zu vermeiden, besser wäre ein Autowert als PS und das Feld nur eindeitig zu indizieren.

Zitatgeht nicht, weil 1. die Nummer vorgegeben wird vom Verband,

Auch mit einem extra Feld lässt sich das wie vom Verband vorgesehen als einzelnes Feld darstellen.

Zitat von: knobbi38 am Oktober 21, 2024, 11:28:38Count() geht nicht, es könnte ja mal ein DS gelöscht werden

Warum? Ich prüfe Count auf 0, wenn ja Nummer vergeben mit 0001, wenn nicht Abfrage mit Max() und um 1 erhöhen.
Klappt perfekt.
Gruß Andi

Zitat von: MzKlMu am Oktober 21, 2024, 11:43:17Das ist ja kein Datum, sondern nur Jahr und Monat. Solche Felder als PS sind zu vermeiden,

Schon klar, aber ich muss mich an Vorgaben vom Verband halten, die Nummer ist per Se eineindeutig.
Und wenn ich neue Mitglieder aus dem Bestand des Verbandes importiere dann muss ich mich an das Schema halten. Und warum ein zusätzlicher ID als Autowert einfügen wenn ich einen eineindeutigen Wert schon habe?

Ich weiß das ist alles andere als Perfekt, aber ich will die DB nicht neustrukturieren sondern einigermaßen wartungsfrei am Laufen halten.

Zitatwarum ein zusätzlicher ID als Autowert einfügen wenn ich einen eineindeutigen Wert schon habe?

Weil du dich um den nicht zu kümmern brauchst, - das ist ein zuverlässiger PK.
Dein Feld kannst du ja trotzdem als eindeutig indexieren.

ZitatUnd wenn ich neue Mitglieder aus dem Bestand des Verbandes importiere dann muss ich mich an das Schema halten.

Ja und, wo ist das Problem beim Import das entsprechend auf zu dröseln.

Hallo Andi,

ZitatIch prüfe Count auf 0, wenn ja Nummer vergeben mit 0001, wenn nicht Abfrage mit Max() und um 1 erhöhen.

Die Prüfung  auf Count()=0 kannst du dir sparen. Überlege mal, was mit Max() zurückgegeben wird, wenn die Anzahl der DS mit den Kriterien = 0 ist.

Beispiel:
nächsterWert = nz(Dmax(...), "0") + 1
Gruß
Ulrich