Hallo!
Ich möchte in Access97 einen Stringvergleich mit Visual Basic machen!
Tabelle:
Set Orga = Db1.OpenRecordset(„DB2USER_TORG“, dbOpenDynaset)
Dafür habe ich folgenden Befehl…
Orga.FindNext ("[Torg_Name] = ‚" &
mdlGEFM & "‘")
bzw. auch probiert:
Orga.FindNext ("[Torg_Name] like ‚" &
mdlGEFM & "‘")
Der String der Konstanten mdlGEFM existiert eindeutig in der Datenbank ohne Blanks hintendran…
Was klappt da net?!?
Da zweifelt man an seinen GRundkenntnissen ;o))
Danke im Voraus
Bernd
Orga.FindNext „[Torg_Name] = '“ & mdlGEFM & „’“
(Klammern gehören da nicht hin) vergleicht den INHALT der Variablen mdlGEFM (ist das eine String-Variable?) mit dem Feld Torg_Name. Ist es das, was du willst?
Am besten zerlegst du mal:
Dim strFind As String
strFind = „[Torg_Name] = '“ & mdlGEFM & „’“
Orga.FindNext strFind
und schaust dir strFind nach der Zuweisung mit dem Debugger an - kommt da ein zulässiger Vergleichsausdruck heraus? (Du kannst den Vergleichsausdruck im Abfrageentwurf-SQL-Fenster als WHERE-Klausel deiner Tabelle testen…)
Ansonsten, beim Suchen mit LIKE sollte es heissen:
Orga.FindNext „[Torg_Name] like '“ & mdlGEFM & „*’“
Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi Reinhard!
Orga.FindNext „[Torg_Name] = '“ & mdlGEFM
& „’“(Klammern gehören da nicht hin)
Sie stören aber auch net… wußte nicht , das es auch ohne geht…
vergleicht den INHALT der Variablen
mdlGEFM (ist das eine String-Variable?)
eine Stringkonstante…
mit dem Feld Torg_Name. Ist es das, was
du willst?
Am besten zerlegst du mal:Dim strFind As String
strFind = „[Torg_Name] = '“ & mdlGEFM &
„’“
Orga.FindNext strFindund schaust dir strFind nach der
Zuweisung mit dem Debugger an - kommt da
ein zulässiger Vergleichsausdruck heraus?
(Du kannst den Vergleichsausdruck im
Abfrageentwurf-SQL-Fenster als
WHERE-Klausel deiner Tabelle testen…)
Danke…etwas ähnliches hatte ich inzwischen schon gemacht… habe den Vergleich beim erstellen des Recordsets eingebaut:
Set Orga = b1.OpenRecordset(„select * from DB2USER_TORG where [TORG_NAME] = mdlGEFM“, dbOpenDynaset)
So klappt es nun, aber mich würde trotzdem schon interessieren, warum das findfirst nicht funzt…an sich ist es ja die gleiche Klausel wie beim findfirst *wunder
Ansonsten, beim Suchen mit LIKE sollte es
heissen:Orga.FindNext „[Torg_Name] like '“ &
mdlGEFM & „*’“
Ups… das hatte ich natürlich vergessen, aber eigentlich war ja auch eine Klausel mit „=“ eingebaut…das like war nur ein Versuch
Zur Info noch… beim Zugriff auf eine DB2-Datenbank hatte es geklappt… nun haben wir die Datenbank auf Oracle umgestellt…nun geht´s nimmer mehr…vielleicht liegts ja auch einfach am Oracle-Treiber…
Reinhard
Bis denne
Bernd
Du bringst die Begriffe Stringkonstante und Stringliteral durcheinander.
Eine Konstante ist für VBA nichts anderes als eine Variable festen Inhalts. Wenn du den feststehenden Text „mdlGEFM“ vergleichen willst (also das Stringliteral), dann musst du schreiben:
Orga.FindNext „[Torg_Name] = ‚mdlGEFM‘“
Reinhard
Hääääääh… wie kommst du denn nu darauf?!?
Nach zig Jahren Programmierung kenn ich den Unterschied inzwischen ;o)))
mdlGEFM ist als Konstante definiert: „Gesellschft für Finanzmarketing mbH“
Bernd
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hääääääh… wie kommst du denn nu
darauf?!?Nach zig Jahren Programmierung kenn ich
den Unterschied inzwischen ;o)))
Ich wollte dir nicht zu nahe treten, aber wenn du schreibst:
Set Orga = b1.OpenRecordset(„select * from DB2USER_TORG where [TORG_NAME] = mdlGEFM“, dbOpenDynaset)
vermengst du Literale, Variablen und Konstanten schon irgendwie…
Bei der Jet-Engine jedenfalls müsste es dort heissen:
Set Orga = b1.OpenRecordset(„select * from DB2USER_TORG where [TORG_NAME] = ‚Gesellschft für Finanzmarketing mbH‘“, dbOpenDynaset)
oder halt:
Dim strGEFM as String
strGEFM = „Gesellschft für Finanzmarketing mbH“
Set Orga = b1.OpenRecordset(„select * from DB2USER_TORG where [TORG_NAME] = '“ & strGEFM & „’“, dbOpenDynaset)
oder halt:
Const cGEFM = „Gesellschft für Finanzmarketing mbH“
Set Orga = b1.OpenRecordset(„select * from DB2USER_TORG where [TORG_NAME] = '“ & cGEFM & „’“, dbOpenDynaset)
das gleiche gilt für FindFirst - die Syntax ist dort identisch mit der SQL-Where-Klausel.
Aber die Behandlung der String-Begrenzungszeichen ist von Datenbank zu Datenbank unterschiedlich. Versuch mal die „normalen“ Anführungszeichen:
Set Orga = b1.OpenRecordset(„select * from DB2USER_TORG where [TORG_NAME] = „““ & cGEFM & „“"", dbOpenDynaset)
Reinhard
Hääääääh… wie kommst du denn nu
darauf?!?Nach zig Jahren Programmierung kenn ich
den Unterschied inzwischen ;o)))Ich wollte dir nicht zu nahe treten, aber
wenn du schreibst:
So schnell bin ich net beleidigt ;o))
Set Orga = b1.OpenRecordset(„select *
from DB2USER_TORG where [TORG_NAME] =
mdlGEFM“, dbOpenDynaset)vermengst du Literale, Variablen und
Konstanten schon irgendwie…
Naja…tipper halt schnell runter da passieren schon mal Tippfehler, aber bei dem Programm wars richtig getippert ;o))
Bei der Jet-Engine jedenfalls müsste es
dort heissen:Set Orga = b1.OpenRecordset(„select *
from DB2USER_TORG where [TORG_NAME] =
‚Gesellschft für Finanzmarketing mbH‘“,
dbOpenDynaset)oder halt:
Dim strGEFM as String
strGEFM = „Gesellschft für
Finanzmarketing mbH“
Set Orga = b1.OpenRecordset(„select *
from DB2USER_TORG where [TORG_NAME] = '“
& strGEFM & „’“, dbOpenDynaset)oder halt:
Const cGEFM = „Gesellschft für
Finanzmarketing mbH“
Set Orga = b1.OpenRecordset(„select *
from DB2USER_TORG where [TORG_NAME] = '“
& cGEFM & „’“, dbOpenDynaset)
das openrecordset funktioniert ja schon längst…mich interessiert halt nur warum dsa findfirst net mehr klappt…
das gleiche gilt für FindFirst - die
Syntax ist dort identisch mit der
SQL-Where-Klausel.Aber die Behandlung der
String-Begrenzungszeichen ist von
Datenbank zu Datenbank unterschiedlich.
Versuch mal die „normalen“
Anführungszeichen:Set Orga = b1.OpenRecordset(„select *
from DB2USER_TORG where [TORG_NAME] = „““
& cGEFM & „“"", dbOpenDynaset)
Hmm… wäre an sich ne gute Idee, aber beim openrecordset funktioniert es mit den einfachen…wäre merkwürdig, wenn´s bei find anders geht, gelle…*weiterwunder
Gruß
Bernd
Welche Schreibweise hast du denn im OpenRecordset verwendet - wirklich die selbe wie beim FindFirst?
Ich hab jetzt ein bisschen die Übersicht verloren…
Reinhard
Orga.FindNext „[Torg_Name] = '“ & mdlGEFM
& „’“(Klammern gehören da nicht hin)
Sie stören aber auch net… wußte nicht ,
das es auch ohne geht…
Sie sind sogar zwingend notwendig, wenn der Feldname z. B. „Torg Name“ lauten würde (also ohne Unterstrich)!
Ist der Name des Feldes in dem gesucht werden soll bei Erstellung des Programms nicht bekannt, z. B. weil die Tabelle und der Feldname vom Anwender zur Laufzeit bestimmt werden, dann mußt Du die Klammern sowieso sicherheitshalber verwenden. Ich verwende sie deshalb grundsätzlich.
Harald
Sie sind sogar zwingend notwendig, wenn
der Feldname z. B. „Torg Name“ lauten
würde (also ohne Unterstrich)!Ist der Name des Feldes in dem gesucht
werden soll bei Erstellung des Programms
nicht bekannt, z. B. weil die Tabelle und
der Feldname vom Anwender zur Laufzeit
bestimmt werden, dann mußt Du die
Klammern sowieso sicherheitshalber
verwenden. Ich verwende sie deshalb
grundsätzlich.
Ich glaube, wir reden über unterschiedliche Klammern - ich meinte die runden Klammern um den Suchausdruck bei FindFirst - die sind entbehrlich bzw. nicht in der Syntax vorgesehen (Findfirst ist eine Methode, keine Funktion!).
Was die eckigen Klammern angeht:
Eine aus meiner Erfahrung bessere Strategie ist, auf Leerzeichen, Unterstriche und vor allem Minuszeichen in Feldnamen generell zu verzichten. (Und dann auch auf die eckigen Klammern - auf sie zu verzichten ist ein guter Test der Qualität der Feldnamen). Mir hat es gerade ein Migrationsprojekt komplett verhagelt, weil die Entwickler Namen wie „[Übersicht Zahlen gesammelt Ist- und Soll-Umsatz nach Jahren]“ verwendet haben. Auch die Länge von Namen ist auf anderen Plattformen stärker begrenzt als in Access - auch in der Hinsicht sollte man sich m.E. nicht allzusehr verausgaben (Von der Lesbarkeit mal ganz abgesehen).
Reinhard
Ich glaube, wir reden über
unterschiedliche Klammern - ich meinte
die runden Klammern um den Suchausdruck
bei FindFirst - die sind entbehrlich bzw.
nicht in der Syntax vorgesehen (Findfirst
ist eine Methode, keine Funktion!).
Du hast recht, die runden Klammern gehören da nicht hin.
Was die eckigen Klammern angeht:
Eine aus meiner Erfahrung bessere
Strategie ist, auf Leerzeichen,
Unterstriche und vor allem Minuszeichen
in Feldnamen generell zu verzichten. (Und
dann auch auf die eckigen Klammern - auf
sie zu verzichten ist ein guter Test der
Qualität der Feldnamen).
Wenn Du selbst die Namen der Felder vergeben kannst mag das sicher richtig sein. Aber unsere Kunden importieren Tabellen in eine DB, auf die dann per Code zugegriffen wird. Da hast Du es nicht mehr im Griff, wie die Feldnamen aufgebaut sind. Wir können den Kunden diesbezüglich auch keine Vorgaben machen, da sie ihrerseits die Daten von dritten bekommen. Deshalb habe ich mir angewöhnt, die eckigen Klammern grundsätzlich zu machen. Damit kann dann nichts mehr schief gehen oder doch?
Harald
Deshalb habe ich mir angewöhnt,
die eckigen Klammern grundsätzlich zu
machen. Damit kann dann nichts mehr
schief gehen oder doch?Harald
Nun ja - das hängt halt sehr von den Randbedingungen der jeweiligen Anwendung ab. Innerhalb von Access ist das sicher die beste Strategie. Aber wenn es z.B. um die Anbindung anderer Software geht (z.B. eben ODBC-Datenbanken), muss man sich zusätzlich um deren Namenskonventionen kümmern.
Leider fangen viele Projekte halt als kleine überschaubare Access-Datenbanken an und ufern dann irgendwann einmal aus. Insofern sollte man sich nach meinen Erfahrungen rechtzeitig (und das heisst i.d.R.: ganz am Anfang) darum kümmern, wie man die Anwendung skalieren kann - also z.B. auf einen SQL-Server migrieren kann.
Aber wie gesagt, es hängt halt ganz von der jeweiligen Anwendung ab. Ich hatte mal eine Anwendung, die von deutschem Access ins türkische gebracht werden sollte - ein schier aussichtsloses Unterfangen, sobald z.B. Umlaute in Namen verwendet werden!
Reinhard
Logo, sosnt würde mich das ganze ja net so verwundern…habe es per copy-place kopiert ;o)
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]