Funktion soll Textfelder füllen

[MzKlMu]

Hallo,
ich fürchte, da liegt noch viel mehr im Argen.

Die Ansprechpartner sind in mehreren Tabellen

Wieso hast Du mehrere Tabellen für die Ansprechpartner?

Ob ich per VBA DLookup verwende (SQL) oder ob ich ne Abfrage erstelle und darauf zugreife. Wo soll da der Unterschied sein?

Na Du musst nichts programmieren. DLookup mit VBA ist kein SQL.

Das ganze Vorhaben lässt sich z.B. mit einem Hauptformular undd darin eingebetteten Unterformularen für z.B. die Ansprechpartner und weitergehende Infos sehr kompfortabel und übersichtlich gestalten. Die Ufos kommen auf Registerblätter. Wenn Hafo und Ufo über die Schlüsselfelder (Kundennummer) verknüpft sind, hast Du in einem Formular eine perfekte Übersicht zum Kunden. In diesem Formular kannst Du vorhandene Kunden suchen oder neue Kunden/Ansprechpartner/Infos anfügen. Dabei wird sogar das Schlüsselfeld automatisch in den abhängigen Tabellen gefüllt. Ohne eine einzige Zeile VBA. So einfach, wie Du es Dir im Moment gar nicht vorstellen kannst.

Wenn Du etwas zum Konzept der DB erklärst, mache ich Dir gern ein Beispiel. Heute Abend.
Du kannst auch mal Deine jetzige DB mit wenigen Datensätzen (anonymisiert) hier hochladen.

[Wurliwurm]

So wie ich das verstehe, geht es dem Frager weniger um Belehrungen zur Tabellenstruktur, sondern wie er Coderedundanz vermeiden kann.

Habe ich recht, wenn ich meine, daß Du in mehreren Formularen immer den gleichen Kopf hast und ihn mit einer zentralen Funktion füllen willst.

Du könntest das evtl. so machen (rudimentärer und abstrakter Code nur um das Prinzip darzustellen)

In den Formularen hast du eine Aufruffunktion

Code [Auswählen] Erweitern

Private Sub auswahlKunde()

Dim intKunde as Integer
intKunde = 4711  'Wert z.B. aus der Kombobox

Dim aktForm As Form 
Set aktForm = Me  'Objektreferenz auf das aktuelle Formular

Call Modul1.getKunde(intKunde, aktForm)  'Zentrale Routine im Modulpool benutzen

End Sub

Im Modul1 gibt es die folgende Routine:

Code [Auswählen] Erweitern

Public Sub getKunde(byval intKunde as Integer, ByRef aktForm As Form)

MsgBox "getKunden wird von Formular " & aktForm.Name & " aufgerufen   ", vbInformation

'Lokale Zwischenvariablen für die Werte aus der Datenbank
Dim strKundenname as string
Dim strPLZ as string
etc... pp.

'Hier kommt eine SQL-Abfrage per DAO oder ADO rein, die Dir die relevanten Daten zum Kunden einliest, DLOOKUP ist nicht so toll, außerdem benützt DLOOKUP sowieso intern SQL, es ist bloß eine Verkapselung von SQL

'Recordset öffnen
    strKundenname = rs!Vorname & " " & rs!Nachname
    strPLZ = rs!Postleitzahl
    ...etc...
'Recordset schliessen

'Jetzt kannst mit der Referenz zur aufrufenden Form (die Du als Übergabeparameter bekommen hast) das aufrufende Formular zurückrufen

Entweder du baust in die Formulare eine Funktion ein, mit der Du die Werte setzt oder Du setzt die Werte gleich direkt, dann müssen die entsprechen Steuerelemente aber unbedingt in allen Formularen gleich heissen.

aktForm.txtKundenname.Value = strKundenname
aktForm.txtPLZ.Value = strPLZ
...etc...

End Sub

Das geht schon ein bißchen in die objektorientierte Programmierung rein, aber ich meine, daß es gehen müßte.

Grüße
Johannes

[oma]

Hallo Falke,

du musst unbedingt deine Einstellung zu Abfragen ändern

Abfragen bzw SQL sind/ist wichtiger Bestandteil einer DB; SQL ist die Datenbanksprache.
Schon  merkwürdig, wenn einer nicht mit den elementaren Werkzeug arbeiten will?

Klaus hat dir doch Tipps gegeben. Sicherlich geht  es auch mit VBA - (siehe Johannes Code) aber der einfache Weg ist doch meistens der bessere


Gruß Oma

[Falke22]

du musst unbedingt deine Einstellung zu Abfragen ändern

Abfragen bzw SQL sind/ist wichtiger Bestandteil einer DB; SQL ist die Datenbanksprache.
Schon  merkwürdig, wenn einer nicht mit den elementaren Werkzeug arbeiten will?

Es ist ja nicht so dass ich damit nicht arbeiten will.

Ich tue mich nur schwer damit Abfragen zu erstellen wenn es in meinen Augen mit VBA vom programmieren her schneller geht
Und DLookUp oder Recordset sind zumindest wenn man der Microsoft Knowledge glauben schenkt VBA-SQL Befehle (weisen ja auch ziemlich die Syntax einer herkömmlichen SQL Abfrage auf

Mag ja sein dass mein DB-Aufbau völlig fürn Arsch ist aber naja glaube d agibt es etliche Varianten und jede hat ihre Vor und Nachteile und bisher laufen meine Datenbanken (wenn ich die Probleme löse) sehr zuverlässig

Greetz

Übrigens sperr eich mich nciht gegen wertvolle Tipps wie die von Klaus, die sicherlich hilfreich sind. Werd die DB jetzt erstmal zusammenkloppen (sitze ein wenig unter Zeitdruck, deswegen kann ich die nicht jetzt nochmal von Grund auf neu machen) und wenn sie dann im Betrieb ist  mich daran machen sie vom Verständnis her "richtig" aufzubauen

[Wurliwurm]

du musst unbedingt deine Einstellung zu Abfragen ändern
Und DLookUp oder Recordset sind zumindest wenn man der Microsoft Knowledge glauben schenkt VBA-SQL Befehle (weisen ja auch ziemlich die Syntax einer herkömmlichen SQL Abfrage auf

DLookUp ist SQL, natürlich. Aber wenn Du fünf mal hintereinander die gleiche Zeile in der gleichen Tabelle aufrufst, mußt Du fünf mal die Schwelle zur Datenquelle überqueren und das kein guter Programmierstil. Das ist, wie wenn Du fünf Sachen vom Supermarkt brauchst und für jede Sache extra hin- und zurück gehst. Kann sein, daß das nicht wirklich spürbar ist im konkreten Fall, aber das solltest Du überdenken.

Grüße
Johannes

[oma]

Hallo,

Ich tue mich nur schwer damit Abfragen zu erstellen wenn es in meinen Augen mit VBA vom programmieren her schneller

he, das ist doch überhaupt kein Argument, man muss anstreben, dass zu machen was am besten ist und nicht das , was man am besten kann. Du musst dich dann eben mit SQL so beschäftigen, dass du das genauso schnell programmieren kannst.

Werd die DB jetzt erstmal zusammenkloppen (sitze ein wenig unter Zeitdruck, deswegen kann ich die nicht jetzt nochmal von Grund auf neu machen) und wenn sie dann im Betrieb ist  mich daran machen sie vom Verständnis her "richtig" aufzubauen

Das sind schon Sprüche
Es gibt Untersuchungen, die aussagen, das das Verhältnis von Konzeptioneller Zeit zu ausführender Programmierzeit bis zu 1:10 geht.
D.h. für 1 Stunde konzeptioneller richtiger Überlegungen am Prinzip sind unter Umständen 10 Stunden Programmierarbeit gespart oder anders ausgedrückt:
1 Stunde mehr Grundsatzüberlegungen hätte 10 Std. Entwicklungszeit(Probieren, Teste, Änders usw.) gespart!

Also : erst zusammenkloppen und dann mal richtig aufbauen ist ein sehr "uneffektiver" Arbeitsstil!

Wir meinen es aber nur gut mit dir

Gruß Oma

[Falke22]

Einen SQL-Befehl per VBA zu schreiben ist doch nciht schlechter als wenn ich ne Abfrage dafür erstelle? Versthe ich nciht warum man so gegen VBA wettert?

Es gibt Untersuchungen, die aussagen, das das Verhältnis von Konzeptioneller Zeit zu ausführender Programmierzeit bis zu 1:10 geht.
D.h. für 1 Stunde konzeptioneller richtiger Überlegungen am Prinzip sind unter Umständen 10 Stunden Programmierarbeit gespart oder anders ausgedrückt:
1 Stunde mehr Grundsatzüberlegungen hätte 10 Std. Entwicklungszeit(Probieren, Teste, Änders usw.) gespart!

Oder (so hab ich es zumindest gelernt) man verbringt bei ordentlicher Programmierung 10 mal mehr Arbeit mit der Konzeptionierung als mit der eigentlichen Programmierung.

Es ist immer noch icht so dass ich kein SQL kann. ICH sehe nur keinen Unterschied zwischen Abfrage erstellen und VBA zu benutzen um die gleiche Abfrage zu realisieren

[oma]

Hallo Falke,

Oder (so hab ich es zumindest gelernt) man verbringt bei ordentlicher Programmierung 10 mal mehr Arbeit mit der Konzeptionierung als mit der eigentlichen Programmierung.

Haja, das wäre ja schlimm, aber 1 Stunde mehr an der Konzeption spart eben einige Stunden in der Programmierarbeit. Ich glaube, dass kann jeder erfahrenen Entwickler bestätigen auch wenn das Prinzip jedesmal bei jedem neuen Projekt wieder auftritt

ICH sehe nur keinen Unterschied zwischen Abfrage erstellen und VBA zu benutzen um die gleiche Abfrage zu realisieren

Vom Prinzip her ist es aber eigentlich so, dass eine deklarative Sprache einfacher und mächtiger ist als ein prozedurale Sprache.
Soll heißen, eine Befehlszeile in SQL ersetzt oft ein paar Schleifen mit Bedingungen in VBA.

Das ist dann nicht nur einfacher zu schreiben, sondern oft ist die DB mit dem SQL scheller als mit dem Schleifen-Gedüdel

Wir wollen es auch nicht übertreiben, denn der Unterschied ist oft nur gering, eigentlich eher eine prinzipielle Debatte


Gruß Oma