6
CAST fehlender Operator
Access 2007, Microsoft Visual Basic 6.5
In einer Suche mit Dlookup wird CAST zur Umwandlung einer im Textformat vorliegenden Zahl zu int verwendet. Als Fehlermeldung Laufzeitfehler 3075 wird ein fehlender Operator angegeben.
Dim Test As Variant
Test = DLookup("MAX(CAST(RIGHT([VersNr],11) AS int))", "Tabelle", "LEFT(VersNr,1) = 'D'")
In der Tabelle ist die Spalte VersNr als Text der Feldgröße 12 definiert. Die gesuchten Nummern lauten z.B. D1430 etc., es soll die größte Nummer gefunden werden. Wo könnte der Fehler liegen ?
Vorab Dake für jede Hilfe, PCFJKG.
In einer Suche mit Dlookup wird CAST zur Umwandlung einer im Textformat vorliegenden Zahl zu int verwendet. Als Fehlermeldung Laufzeitfehler 3075 wird ein fehlender Operator angegeben.
Dim Test As Variant
Test = DLookup("MAX(CAST(RIGHT([VersNr],11) AS int))", "Tabelle", "LEFT(VersNr,1) = 'D'")
In der Tabelle ist die Spalte VersNr als Text der Feldgröße 12 definiert. Die gesuchten Nummern lauten z.B. D1430 etc., es soll die größte Nummer gefunden werden. Wo könnte der Fehler liegen ?
Vorab Dake für jede Hilfe, PCFJKG.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 123812
Url: https://administrator.de/contentid/123812
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
ich bin nicht sicher ob MS Access Funktionen innerhalb der Domänen-Funktionen (DLookup, DMax etc) ausführen kann.
Lösungsvorschlag: Erstelle eine Abfrage, die das Feld der Tabelle entsprechend modifiziert, d.h. RIGHT(...) und CAST(...) bereits enthält. Dann frage diese Abfrage mit DMax() ab.
btw. Gibt es in Access-SQL wirklich die Funktion cast()? Sonst versuch es mal mit val(...)
Gruß
Stefan
ich bin nicht sicher ob MS Access Funktionen innerhalb der Domänen-Funktionen (DLookup, DMax etc) ausführen kann.
Lösungsvorschlag: Erstelle eine Abfrage, die das Feld der Tabelle entsprechend modifiziert, d.h. RIGHT(...) und CAST(...) bereits enthält. Dann frage diese Abfrage mit DMax() ab.
btw. Gibt es in Access-SQL wirklich die Funktion cast()? Sonst versuch es mal mit val(...)
Gruß
Stefan
Moin PCFJKG,
ich weiß nicht...
Manche Probleme sollte man/frau nicht zu lösen versuchen, sondern einfach gar nicht heraufbeschwören.
1. Wenn Du die "höchste" vergebene VersNr finden willst, die mit "Dnnnn" beginnt, dann schenkt Dir das versuchte Umformen auf einen INT. nimm einfach ein "Max(VersNr)".
2. Wenn Du schon nicht darauf hören willst, dann nimm statt der schlampig hingebratzten CAST-Funktion die CInt()-Funktion
> ..Test = DLookup("MAX(CInt(RIGHT([VersNr],11) ))", "Tabelle", "LEFT(VersNr,1) = 'D'")
3. Wenn Du schon in einen INT (was auch immer Access darunter zu verstehen vorgibt) konvertieren willst, dann überprüf noch mal, ob für einen INT-Wert denn die rechten elf (11!!) Zeichen eines Strings nicht ein bisschen ruppig sind.
Ein Test mit
liefert jedenfalls (logischerweise) sofort einen "Überlauf", wenn es in einem KlickiBunti-Query-Fenster angestupst wird.
Grüße
Biber
ich weiß nicht...
Manche Probleme sollte man/frau nicht zu lösen versuchen, sondern einfach gar nicht heraufbeschwören.
1. Wenn Du die "höchste" vergebene VersNr finden willst, die mit "Dnnnn" beginnt, dann schenkt Dir das versuchte Umformen auf einen INT. nimm einfach ein "Max(VersNr)".
2. Wenn Du schon nicht darauf hören willst, dann nimm statt der schlampig hingebratzten CAST-Funktion die CInt()-Funktion
> ..Test = DLookup("MAX(CInt(RIGHT([VersNr],11) ))", "Tabelle", "LEFT(VersNr,1) = 'D'")
3. Wenn Du schon in einen INT (was auch immer Access darunter zu verstehen vorgibt) konvertieren willst, dann überprüf noch mal, ob für einen INT-Wert denn die rechten elf (11!!) Zeichen eines Strings nicht ein bisschen ruppig sind.
Ein Test mit
SELECT CInt("1234") as castedshort2int,
cint ("12345678901") as An11charsLongString
From irgendneTabelleGrüße
Biber
Hallo Biber,
habe die Kritik verstanden (bloß nicht ganz verstanden warum cast schlampig war, denn auf dem SQL-Server funktionierte sie so ...).
Egal, CInt() ist ok und löst mein Problem wunderbar, MAX([VersNr]) funktioniert leider nicht, liefert z.B. bei 10 vorhandenen VersNrn
D1
D2
...
D9
D10
die D9 ...
Nun kann ich aber weiter, vielen DANK auch an Stefan (stupsnose) und eine schöne Woche wünscht
PCFJKG
habe die Kritik verstanden (bloß nicht ganz verstanden warum cast schlampig war, denn auf dem SQL-Server funktionierte sie so ...).
Egal, CInt() ist ok und löst mein Problem wunderbar, MAX([VersNr]) funktioniert leider nicht, liefert z.B. bei 10 vorhandenen VersNrn
D1
D2
...
D9
D10
die D9 ...
Nun kann ich aber weiter, vielen DANK auch an Stefan (stupsnose) und eine schöne Woche wünscht
PCFJKG
Hallo Stefan,
ich konnte das Problem mit CInt() an Stelle von Cast() lösen (siehe auch Antwort Biber).
Eine schöne Woche wünscht
PCFJKG
ich konnte das Problem mit CInt() an Stelle von Cast() lösen (siehe auch Antwort Biber).
Eine schöne Woche wünscht
PCFJKG
Moin PCFJKG,
okay, eine "Max(VersNr)" wie von mir vorgeschlagen würde in der Tat nicht funktionieren, wenn diese "VersNr"-Strings unterschiedliche Längen haben (also "D1" existiert und auch "D12" und "D1111").
Da kommt natürlich bei der alphanummerischen MAX()-Auswertung eine andere Reihenfolge als die nach den Zahlenwerten geordnete.
Zu der Nachfrage bezüglich "der schlampig hingebratzten CAST-Funktion".
Damit meinte ich nicht Deine Umsetzung, sondern die ziemlich halbgare Implemetierung seitens der RedmonderInnen.
Das Typische dabei ist, dass "allgemein als Standard erwartete Funktionen" wie bei SQL halt CAST/CONVERT schon irgendwie umgesetzt werden, aber eben "der Form halber".
So wie bei der meisten (verkauften) Software "der Form halber" auch irgendein Hilfefenster aufpoppt wenn F1 gedrückt wird.
Also es ist schon etwas vorhanden. Aber es hat unübersehbar Potentiale.
<OT>
Ein ähnliches Dauerärgernis-Thema der "pro forma"-realisierten Standardfunktionen sind beispielsweise die bei ADO/DAO ja höchst individuell auseinanderlaufenden Methoden der RecordSet-Objekte.
Ein buchstabengleiches "rst.Find" mit einem DAO-Recordset kann ein ganz anderes Ergebnis bringen als ein "rst.Find" mt einem ADO-Object.
Und das ist nicht die Form von Kompatibilität, die ich mir erhoffe eigentlich.
</OT>
Grüße
Biber
okay, eine "Max(VersNr)" wie von mir vorgeschlagen würde in der Tat nicht funktionieren, wenn diese "VersNr"-Strings unterschiedliche Längen haben (also "D1" existiert und auch "D12" und "D1111").
Da kommt natürlich bei der alphanummerischen MAX()-Auswertung eine andere Reihenfolge als die nach den Zahlenwerten geordnete.
Zu der Nachfrage bezüglich "der schlampig hingebratzten CAST-Funktion".
Damit meinte ich nicht Deine Umsetzung, sondern die ziemlich halbgare Implemetierung seitens der RedmonderInnen.
Das Typische dabei ist, dass "allgemein als Standard erwartete Funktionen" wie bei SQL halt CAST/CONVERT schon irgendwie umgesetzt werden, aber eben "der Form halber".
So wie bei der meisten (verkauften) Software "der Form halber" auch irgendein Hilfefenster aufpoppt wenn F1 gedrückt wird.
Also es ist schon etwas vorhanden. Aber es hat unübersehbar Potentiale.
<OT>
Ein ähnliches Dauerärgernis-Thema der "pro forma"-realisierten Standardfunktionen sind beispielsweise die bei ADO/DAO ja höchst individuell auseinanderlaufenden Methoden der RecordSet-Objekte.
Ein buchstabengleiches "rst.Find" mit einem DAO-Recordset kann ein ganz anderes Ergebnis bringen als ein "rst.Find" mt einem ADO-Object.
Und das ist nicht die Form von Kompatibilität, die ich mir erhoffe eigentlich.
</OT>
Grüße
Biber
Hallo Biber,
danke auch für diese tröstlichen Worte denn:
solange Leute wie Du in der Lage und willens sind, diese beschriebenen und andere Sorgen von uns Nutzern zu lösen, kommt man zumindest weiter und die oft so nach und nach aufkommenden "Zweifel am eigenen Verstand" wurden wieder (zumindest teilweise) genommen. Das ägerliche ist tatsächlich die unnötig verschwendetet Zeit; vom Nervenkostüm (je nach aktueller Stimmungslage) ganz zu schweigen.
Im Moment ist für mich die Welt wieder einigermaßen in Ordnung, nicht zuletzt dank Deiner Hilfe (übrigens nicht zu ersten mal).
Also again: thanks a lot and best wishes from
PCFJKG
danke auch für diese tröstlichen Worte denn:
solange Leute wie Du in der Lage und willens sind, diese beschriebenen und andere Sorgen von uns Nutzern zu lösen, kommt man zumindest weiter und die oft so nach und nach aufkommenden "Zweifel am eigenen Verstand" wurden wieder (zumindest teilweise) genommen. Das ägerliche ist tatsächlich die unnötig verschwendetet Zeit; vom Nervenkostüm (je nach aktueller Stimmungslage) ganz zu schweigen.
Im Moment ist für mich die Welt wieder einigermaßen in Ordnung, nicht zuletzt dank Deiner Hilfe (übrigens nicht zu ersten mal).
Also again: thanks a lot and best wishes from
PCFJKG
