Parameterwert eingeben

[thron]

Hallo,

verzweifle bald. Habe eine Abfrage geschrieben und jedes mal wenn ich das Dropdownfeld auswähle kommt "Parameterewert auswählen" und darunter Formular!frm_anpsrechpartner2!cmb_suchen

Das Dropdownfeld heißt auch cmb_suchen..ich weiß nicht was ich falsch mache!!

Syntax:
"Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE ([marken1] = Formular![frm_anpsrechpartner2]![cmb_suchen])"

[DF6GL]

Hallo,

Code [Auswählen] Erweitern

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE [marken1] =  Forms![frm_anpsrechpartner2]![cmb_suchen] "

oder besser:

Code [Auswählen] Erweitern

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE [marken1] = '" & Me!cmb_suchen & "'"

falls marken1  vom Datentyp Text ist.

Bei Zahl, Long:

Code [Auswählen] Erweitern

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE [marken1] = " & Me!cmb_suchen

[Lachtaube]

Antwort 2 ist aber nur deswegen besser, weil Antwort 1 nicht funktioniert. Da müsste man sich schon auf Forms oder das deutsche Formulare beziehen, was auch der Azfbau-Assistent verwenden würde.

Ansonsten gilt es immer das Zusammensetzen von SQL-Ausrücken zu meiden, wo Benutzereingaben mit einfließen können - Stichwort: SQL-Injection.

[thron]

hallo...

also jetzt kommt zwar keine Fehlermeldung aber er zeigt mir den Datensatz nicht an. Es passiert einfach nichts. Vorher habe ich nachdem ich in die Abfrage z.B. BMW eingetragen hatten ein Ergebnis bekommen!?

[MaggieMay]

Hi,

vielleicht ließe sich das Problem mit dem Einsatz von korrekter Schreibweise evtl. schon leichter lösen.

Es heißt weder "anpsrechpartner" noch "Anprechpartner" noch "anpsrechpartner".
Drei Fehlervarianten bzgl. eines Begriffs innerhalb eines recht kleinen Code-Auszugs stimmen schon bedenklich. Oder wie siehst du das?!

Ich würde als erstes da ansetzen und die Namensgebung überprüfen und wo nötig korrigieren.

PS:
Möglicherweise sind dies alles aber auch nur Tippfehler.
Und genau aus diesen Gründen sind Code-Auszüge hier stets per Copy & Paste einzufügen und niemals freihändig einzutippen.

[DF6GL]

Hallo,


@Lachtaube:

Antwort 2 ist aber nur deswegen besser, weil Antwort 1 nicht funktioniert.

das ist nicht richtig.

Da müsste man sich schon auf Forms oder das deutsche Formulare beziehen,

da steht  "Forms"  ....

Ansonsten gilt es immer das Zusammensetzen von SQL-Ausrücken zu meiden, wo Benutzereingaben mit einfließen können - Stichwort: SQL-Injection.

??

Wir sprechen hier von einer Access-Databaseengine, und das Zusammensetzen (concat) eines SQL-Strings per VBA und Zuweisen an eine passende Eigenschaft hat (in der gezeigten Form) noch nie zu irgendwelchen Problemen geführt. Allenfalls sind mögliche Fehlersituationen abzufangen, z. B. wenn die verwendete Kombispalte leer (NULL bzw vbNullstring)  ist.

(Performance-Betrachtungen und andere lass ich hier mal außen vor, weil völlig irrelevant.)

[Lachtaube]

Sorry Franz - das ist dann meinen schlechten Augen zu schulden.

Genau so eine Antwort zu 2 habe ich erwartet.  Was in allen andern Programmierumgebungen bezogen auf Datenbanken als verpönt gilt, sollte man sich mMn erst gar nicht angewöhnen. Möge man hoffen, dass nie ein Upgrade auf einen Server stattfindet.

[DF6GL]

Hallo,

Möge man hoffen, dass nie ein Upgrade auf einen Server stattfindet

Ich denke, das kommt in dieser Umgebung hier (Access-Board) eher äußerst selten vor.

Aber wie es auch sein, Lastzüge müssen halt anders bedient (gefahren) werden, als eine Schubkarre. 

[Beaker s.a.]

Hallo,
@Franz @Lachtaube
Bitte nicht schlagen, aber ich habe ja auch manchmal Tomaten auf den Augen.

Antwort 2 ist aber nur deswegen besser, weil Antwort 1 nicht funktioniert.

das ist nicht richtig.

Warum? IMO ist im ersten String ein Syntaxfehler:

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE [marken1] =  '" & Forms![frm_anpsrechpartner2]![cmb_suchen] & "'"

Nehmt mit bitte die Tomaten ab (Mozarella müsst ihr selbst besorgen ).
gruss ekkehard

[Lachtaube]

Syntaxfehler würden im VBA-Editor als solche markiert werden.

[Beaker s.a.]

Hallo,
Ja, stimmt.
Mein Denkfehler hat sich inzwischen auch verflüchtigt. 
gruss ekkehard

[DF6GL]

Hallo,


wo genau vermutest Du Syntax-Fehler (Benamsungsfehler mal ausgenommen)?

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE [marken1] =  '" & Forms![frm_anpsrechpartner2]![cmb_suchen] & "'"

ist gleichbedeutend mit Code 2 in meinem Posting.


Hierzu:

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE [marken1] =  Forms![frm_anpsrechpartner2]![cmb_suchen] "

wurde behauptet, das ginge nicht.  Solche Formular-Steuerelement-Verweise werden vom Expression-Service passend zum Datentyp des Tabellenfeldes aufgelöst. D. h. dieser Ausdruck funktioniert sowohl bei Datentyp "Text" als auch bei "Zahl". Hierbei sind bei Text auch keine Hochkommata nötig. Allerdings funktioniert diese Auflösung nicht unbedingt überall bei Einsatz eines solchen SQL-Strings.

Im Eingangspost ist lediglich der Form-Objekt-Verweis falsch geschrieben:

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE ([marken1] = Formulare![frm_anpsrechpartner2]![cmb_suchen])"

der auch nur im deutschen Access funktioniert. Sicherer ist, statt Formulare  Forms zu schreiben, oder wie schon gesagt, solche SQL-internen Verweise ganz bleiben zu lassen und den Verweis in/nach VBA auszulagern (mögliche Datenbank-Migrationen auf andere DB-Systeme außen vor gelassen  ):

Me.RecordSource = "SELECT * FROM tbl_Anprechpartner WHERE ([marken1] = '" & Forms![frm_anpsrechpartner2]![cmb_suchen]) & "'"

(Hierbei Datentyp beachten--> Hochkommata)

[Beaker s.a.]

Hallo Franz,
Danke für deine Mühe.

Solche Formular-Steuerelement-Verweise werden vom Expression-Service passend zum Datentyp des Tabellenfeldes aufgelöst.

Das war die entscheidende Tatsache, die mir inzwischen klar geworden ist,
und am  Anfang durch besagte Tomaten verdeckt war 
gruss ekkehard

[thron]

Also bei mir funktioniert es mittlerweile, dank Eurer Hilfe...

Vielen Dank...

[PhilS]

Wir sprechen hier von einer Access-Databaseengine, und das Zusammensetzen (concat) eines SQL-Strings per VBA und Zuweisen an eine passende Eigenschaft hat (in der gezeigten Form) noch nie zu irgendwelchen Problemen geführt. Allenfalls sind mögliche Fehlersituationen abzufangen, z. B. wenn die verwendete Kombispalte leer (NULL bzw vbNullstring)  ist.

Ein Angriff über SQL-Injection ist in einem reinen Access-Szenario in der Tat eher abwegig. Das grundlegende technische Problem ist aber auch hier durchaus relevant.

Was passiert, wenn in das Suchfeld eine Name mit einem Hochkomma wie z.B."D'Marco" eingetragen wird? Natürlich kann man auch dies behandeln, aber das Beispiel unterstreicht den Einwand von @Lachtaube, dass man User-Input nicht ungeprüft weiterverarbeiten sollte.