Letzte Hoffnung

[stoppi12]

Servus,

Ich bin gerade dran ein Front End zu erstellen und habe einige Baustellen . Hauptpunkt ist, dass ich ein Formular habe, das alle Bauteile auflistet (Form1) und ein Formular, das zu jedem Bauteil spezifische Informationen enthält (Form2, ID-Feld: detailsid). Das Bauteil Form1 hat eine Spalte ID (partsid) für jedes Bauteil und ist ein Endlosformular. Nun möchte ich, dass wenn man ein Bauteil aus Form1 klickt, man zu Form2 geleitet wird und einem das Bauteil angezeigt wird.
Fehler: Es wird ein Parameter für das ID-Feld von Form2 verlangt. Wenn ich jedoch einen Wert eingebe, erscheint auch nicht das gewünschte Bauteil, sondern ein leeres Form ohne Daten.

Code fürs Doppelklicken auf den Namen des Endlosformulars:

Private Sub Text59_DblClick(Cancel As Integer)
    Dim id As Integer
    id = Me![partsid]
    DoCmd.OpenForm "Bauteil Info 2", , , "detailsid = " & id
End Sub


Kannst mir diesbezüglich jemand helfen? Gerne auch per Teams-Call, wenn es Recht ist.

VG Henry

[Bitsqueezer]

Hallo,

am einfachsten ist immer, eine entsprechende Demodatenbank mit den nötigen Elementen zu erstellen und mit ein paar Demodatensätzen hochzuladen.
Einen Teams-Call wird wohl keiner hier machen, ist ja keine 24h-Support-Notdienststelle...
Es ist ein Forum, also müßtest Du erst einmal die notwendigen Informationen liefern.

Wenn so eine Inputbox aufpoppt, stimmt meistens in der Abfrage des Formulares etwas nicht, es wird ein Feld erwartet, das nicht existiert und Access fragt dann alternativ nach dem Wert.

Du kannst es aber auch viel einfacher machen, indem Du Form2 in Form1 als Unterformular einbaust.
Stelle das UFo einfach in den Fußbereich, als erstes kommt eine Fehlermeldung, daß das mit einem Endlosformular nicht geht. Die Meldung ignorieren und das HFo einfach wieder auf Endlos einstellen.

Das UFo verbindest Du dann über die partsid mit dem HFo und Du bist fertig.
Wenn Du jetzt eine Zeile im Detailbereich des HFo anklickst, werden Dir im UFo alle zugehörigen Details gelistet. So einfach kann das Leben sein.

Gruß

Christian

[stoppi12]

Danke für die Antwort.
Aber ist das dann nicht alles in einer Ansicht für den Nutzer?
Ich möchte eine Ansicht mit der Auflistung aller Bauteile und wenn er (der Nutzer) dann auf ein beliebiges Bauteil klickt, soll er zu der Ansicht des Bauteils weitergeleitet werden. Außerdem erscheinen bei mir die Möglichkeiten verknüpfen von/ nach gar nicht. Vermutlich weil beide Formulare unterschiedliche Abfragen als Datenquelle verwenden. Wir haben nämlich die Daten nicht in access, sondern in einer externen PostGre SQL Datenbank.
VG

[Bitsqueezer]

Hallo,

ja, sind in dem Fall in einer Ansicht. Alternativ kannst Du das gleiche erreichen, indem Du ein HFo mit zwei Registerkarten erstellst, eins mit dem jetzigen HFo (dann natürlich ohne das UFo im Fuß) und eins mit dem 2. Formular als UFo.
Dann stellst Du eine ungebundene Textbox im neuen HFo und bindest nur das 2. UFo (mit den Details) an dieses Control (nicht an das Feld, an das Control, das, wie immer, einen anderen Namen als das Feld haben sollte, also z.B. "ctlPartsid").

Die Verbindung mußt Du manuell einstellen, wenn Du das UFo-Control selektiert hast. Dort dann als Quelle den Control-Namen im HFo einstellen und als Ziel den Feldnamen (nicht den Controlnamen) im UFo. Das verbindende Element des 2. UFos ist also die Textbox aus dem übergeordneten HFo. Das erste UFo wird dagegen nicht mit Link-Feldern verbunden, da es sonst nur genau 1 Zeile anzeigen würde.

In Form_Current des ersten UFos stellst Du dann ein "Me.Parent.ctlPartsid = Me.ctlPartsid" (unter der Annahme, daß es ein Control "ctlPartsid" im ehemaligen HFo gibt, das an partsid gebunden ist).

Ergebnis: Wenn Du nun eine Zeile im 1. UFo anklickst, wird der aktuelle ID-Wert in die Textbox im übergeordneten HFo geschrieben und da dieses das Link-Feld zum 2.UFo darstellt, wird dieses automatisch auf diese id gefiltert.

Der Rest ist nun Geschmackssache, wie Du das dem Anwender präsentierst:

• Du kannst beim Wechsel im 1. UFo gleich auf den 2. Tab wechseln und die Details zeigen. Wahrscheinlich eher unbefriedigend.
• Du kannst im 1. UFo einen Button einbauen, der nur bei Klick die ID in die übergeordnete Textbox kopiert (also statt Form_Current), damit kann der User sich im 1. bewegen, ohne jedesmal die Daten im 2. zu laden, wenn er diese noch gar nicht sehen will, was auch Performance spart.
• Der Button kann dann auch den Tab im übergeordneten Formular wechseln und so das 2. sichtbar machen
• Alternativ überläßt Du das dem User, der dann bei Bedarf auf den 2. Tab klickt, nachdem er den Button geklickt hat. In dem Fall ist es allerdings sinnvoller, keinen Button einzubauen und stattdessen den Wechsel des Tabs zu verwenden, die ID aus dem 1.UFo in die Textbox zu kopieren, somit kannst Du Dich im 1. Formular frei bewegen, ohne daß etwas im 2. passiert, und sobald Du auf den 2. Tab klickst, wird dann erst auf die Details gefiltert und der Tab sichtbar.
• Wenn Du keine Tabs willst, kannst Du im Tabcontrol auch einstellen, daß diese nicht sichtbar sind. Die einzelnen Tabs gibt es dennoch weiterhin, nur kann sie dann der User nicht mehr klicken, d.h. in dem Fall mußt Du die Steuerung über Buttons in beiden UFos durchführen. Also im 1. für "Details" und im 2. für "zurück".
• Ich persönlich finde es praktischer, beides zusammen sichtbar zu haben wie in meinem 1. Vorschlag, da man nicht viel klicken muß und sofort alle Informationen auf einer Seite hat. Aber das bleibt ja Dir überlassen

Ich habe mit den PostgreSQL-Datenbanken keine gute Erinnerung an Verbindung zu Access als Frontend, die Verarbeitung war immer extrem langsam. Das ist aber schon 10 Jahre her, und wie gut damals die Backend-Datenbank war (Indizierung usw.) weiß ich auch nicht. Hoffe, das ist mittlerweile besser geworden..

Gruß

Christian

[stoppi12]

Hallo Christian,

danke für deine Hilfe. Letztendlich lag es einfach daran, dass ich nach dem Feldnamen der ID in meinem Detailformular gefiltert habe, anstatt den Filter auf den Feldnamen der ID, der Abfrage (Datenquelle meines Deatilformulars).

Nun funktioniert der Übergang nahtlos mit den richtigen Daten.

VG Henry

[stoppi12]

Hallo nochmal Christian
Zu deiner Thematik mit der PostgreSQL Datenbank. Unsere ursprüngliche Datenbank hat ca. 200MB und 5 aktive Nutzer, war jedoch Performance-mäßig so schlecht aufgestellt, dass sie ca. 1 min zum Laden beim erstmaligen Öffnen braucht und auch im Bearbeitungsmodus sehr langsam ist.

Was wäre denn deine Lösung/Ansatz für diese Topic?

VG Henry

[Bitsqueezer]

Hallo,

ich kann natürlich nicht sagen, ob es an der Datenbank liegt, aber wir hatten damals das Problem, daß es manchmal mehr als 2 min. gebraucht hat, um von einer eigentlich einfach aufgebauten Abfrage Ergebnisse in Access zurückzubekommen.

Die Menge der Daten war dabei vielleicht ein paar tausend Datensätze, also nichts, was eine Datenbank nicht aus dem Ärmel husten würde.

Bei 200MB würde ich die Datenbank von Dir auch mal als eher sehr klein einschätzen. Und bei 5 Benutzern ist dann auch die Frage, ob es sich nicht lohnen würde, in ein anderes Datenbanksystem zu investieren, aber das hängt natürlich auch vom Aufwand ab, weil es u.U. viel Neuprogrammierung benötigt.
Ich kann nur aus meiner wenigen Erfahrung mit PostgreSQL sagen, daß es jedesmal Performance-Probleme im Zusammenhang mit Access gab, auch bei völlig unterschiedlichen Kunden mit völlig unterschiedlichen Datenbanken. Das ist aber nicht repräsentativ, ob und welche Lösungen es da vielleicht gäbe, kann ich nicht beurteilen.

Mein persönliches "schlechtes Gefühl" mit PostgreSQL ist zumindest für mich Grund genug, daß ich selbst nie auf PostgreSQL setzen würde. Aber Andere haben da sicher ganz andere Erfahrungen gemacht. Immerhin ist die Datenbank ja sehr verbreitet und würde wohl kaum mehr auf dem Markt sein, wenn sie per se so schlecht wäre.

Abhängig davon, was man damit in Access machen will, würde ich ggf. eine Zwischenlösung verwenden. Wenn Access nur zur Auswertung oder Weiterverarbeitung als Einbahnstraße dienen soll und Live-Daten nicht so wichtig sind, würde ich z.B. einen SQL Server (und sei es nur Express) dazwischenschalten und diesen per Agent Job damit beschäftigen, Daten mit PostgreSQL abzugleichen, also abzuholen und in einer eigenen Datenbank vorzuhalten, die dann auch schon Vorarbeit in der Verarbeitung der Daten leisten könnte, und Access könnte dann die Daten von dort abholen, schon auifbereitet, was dann zu keinem Performance-Problem mehr führen dürfte.
Abhängig davon, wie oft so ein Abgleich stattfindet, ist dann die Aktualität der Daten. Aber beispielsweise in Data Warehouse-Datenbanken ist es Standard, aus Live-Daten das DWH zu bilden in z.B. nächtlichen Datenabgleich-Läufen, um Reporte zu beschleunigen und Daten in redundanten Tabellen zu halten, die dem Nicht-DWHler die Haare zu Berge stehen lassen, aber durch ihre redundante Arbeitsweise extrem effizient für Reporte sind.

Also, man kann sowas nie allgemein formulieren, um eine Lösung zu finden, die für alle paßt, muß man immer jeden Fall einzeln genau auseinandernehmen.

Gruß

Christian

[stoppi12]

Hallo Christian,

vielen Dank für deine Einschätzung. Ich habe noch eine kurze Frage zu meiner Gesamtsituation, da du in diesem Bereich sehr bewandert bist.

Derzeit absolviere ich ein Praktikum in einem großen Konzern und bin mit der Entwicklung einer Datenbank sowie des dazugehörigen Front-Ends beauftragt. Leider bin ich in diesem Bereich fachfremd, was meine Arbeit erheblich erschwert und wahrscheinlich auch für meine Nachfolger problematisch sein wird. Mein aktueller Workflow besteht darin, den Großteil des Tages damit zu verbringen, Funktionen für die Datenbank zu entwerfen, indem ich mir von KI VBA-Code generieren lasse. Dieser funktioniert jedoch oft nicht oder scheitert bei der Ausführung einer anderen Operation. Es fühlt sich an wie ein Hamsterrad, das nur langsam und komplizierte Ergebnisse liefert.

Das Backend, das in PostgreSQL geschrieben wurde, wurde von einem anderen Praktikanten entwickelt, der nun nicht mehr im Unternehmen ist. Daher war ich von Anfang an nicht vollständig in das Projekt involviert.

Wie würdest du in meiner Situation vorgehen, um das Problem zu lösen?

Vielen Dank für deine Hilfe.

Beste Grüße,
Henry

[Bitsqueezer]

Hallo Henry,

naja, ob ich der richtige bin, Deine berufliche Situation einzuschätzen, also meine Fachkenntnisse gehen wohl eher in Richtung Datenbankdesign...

Also die Situation ist: Ein Praktikant, der nicht mehr verfügbar ist, entwickelt ein Backend-Design, mit dem Du nicht vertraut bist. Und ich vermute, Deine Kenntnisse in PostgreSQL sind auch eher dünn?

VBA ist auch nicht Deine Welt, aber Du entwickelst ein Frontend mit VBA, ebenfalls als Praktikant, also zeitlich begrenzt.

Wie soll man sagen... es klingt nicht gerade nach einem durchdachten Projekt, sondern eher nach einer "Schnelllösung" mit "preiswerten" Arbeitnehmern, vermutlich ist das Projekt auch nicht sonderlich kriegsentscheidend, wenn im Backend nur 5 User damit arbeiten und nur 200MB Datenbankgröße zusammengekommen ist.

Mit den wenigen Informationen würde ich mir an Deiner Stelle überlegen, welches Ziel Du Dir persönlich gesetzt hast. Der eigentliche Zweck eines Praktikums besteht ja darin, in die Arbeitsweise eines Wunschunternehmens hineinzuschnuppern und festzustellen, ob einem der Job liegt und man sich vorstellen kann, sowas als Festeinstellung vielleicht ein Leben lang zu machen.

Also stelle Dir als erstes die Frage: Was erwartest Du selbst von diesem Praktikum und was möchtest Du hier lernen?
Wenn Du Frontendentwicklung mit VBA machen möchtest, also weitestgehend Access und vielleicht ein wenig Excel und ggf. noch weniger Word und am wenigsten PowerPoint, dann wäre mein persönliches Vorgehen, mich mit vor allem der Programmiersprache VBA auseinanderzusetzen und diese wirklich zu lernen.

Dabei kann man sagen, daß das eigentliche VBA einen sehr geringen Sprachumfang hat und man sehr schnell auf die Kette bekommen sollte, wie VBA funktioniert und wie man Programme damit schreibt.
Aber die Programmiersprache allein ist normalerweise immer der geringste Teil. Diese macht aus, was Variablen sind, wie man welche einsetzt, If/For/Do While/Function/Sub usw. kennenzulernen und das war's auch schon mit VBA. Die Sprache ist so einfach strukturiert, sollte man schnell gelernt haben.
Das nächste Konzept ist das Verstehen von Objekten und Klassen. Wenn man damit umgehen kann, hat man schon eine große Grundlage für diese und viele weitere Programmiersprachen.

Der aber viel größere Aufwand ist das Erlernen der Umgebung. VBA ist mit Visual Basic for Applications konkret abhängig von der Umgebung. Also Access, Excel, Word, PowerPoint und einige wenige externe Hersteller wie CorelDraw usw., die VBA implementiert haben.
Jede dieser Anwendungen hat einen anderen Zweck und bringt einen Riesenhaufen Libraries, Objekte usw. mit, die genau zu dieser einen Anwendung gehören. Zusätzlich kann man andere einbinden und für jede kommt dann ein weiterer, völlig anderer Block an Objekten hinzu, die nichts mit dem einer anderen Anwendung zu tun haben. Wie einem Excel-Sheet oder -Range oder einer Access-Tabelle oder -Abfrage.
Will man also Access programmieren, muß man sich auch mit dem gesamten Produkt befassen. Während Excel und Word etwa einen "Makrorekorder" mitbringen, die einem VBA anhand von Tätigkeiten in der Anwendung selbst erstellen (wenn auch nicht "gut", aber immerhin eine Grundlage), muß man etwa in Access alles selbst lernen.
Und Access ist bei weitem umfangreicher zu lernen als Excel etwa. Denn Access ist eine Datenbank und so muß man neben VBA auch Datenbankdesign und vor allem SQL lernen, auch wenn man anfänglich noch mit Abfragedesignern zum Ziel kommen kann.

Und hier beginnt Deine persönliche Entwicklung: Willst Du das überhaupt in Deiner beruflichen Zukunft machen? Oder willst Du nur einen Einstieg in die IT und eigentlich später etwas ganz anderes in der IT machen, und wenn ja, was? Davon würde ich es abhängig machen, wieviel Energie Du hier investierst.

Es ist nicht verwerflich oder falsch, sich von KI helfen zu lassen, denn die sind mittlerweile ziemlich gut, auch wenn sie im Fall von VBA gerne noch immer VBA und VB.NET durcheinanderbringen oder die Objektmodelle von Access und Excel usw. Mittlerweile gibt es auch spezialisierte KI, die nur auf bestimmte Themengebiete trainiert wurden und viel bessere Ergebnisse liefern. Dennoch: Sie liefern auch nicht selten fehlerhaften oder gar unbrauchbaren Code, und sind dann eigentlich nur eine wirkliche Hilfe, wenn man den Code, den sie liefern, selbst versteht und nicht einfach Copy/Paste-"Programmierung" macht, also einfügen und hoffen, daß es läuft, dann aber nicht verstehen, warum nicht.
Das bringt Dich nicht weiter, also beschäftige Dich mit der Programmiersprache, bis Du sie drauf hast und die KI auf ihre Fehler hinweisen kannst. Du glaubst nicht, wie oft sich eine KI für ihre Fehler entschuldigen kann...
Gemini ist da besonders witzig, mit jeder Korrektur kommt sowas wie "Dies ist nun der wirklich endgültige und getestete und komplett korrekte Code...", auch nach dem 10. Fehlversuch...
Ich habe dazu auch schon mal geschrieben: "Du solltest "endgültig" nicht schreiben, wenn du dir nicht wirklich sicher sein kannst und du kannst den Code nicht getestet haben, da das eine Laufzeitumgebung voraussetzen würde". Das hat Gemini dann auch kleinlaut zugegeben...

Also: KI hilft, viel Zeit zu sparen, um Codegrundlagen schnell zu generieren, was sonst sehr viel Schreibarbeit wäre. Besonders nice ist der Copilot, wenn man das Addon in Visual Studio Code aktiviert, da man die Codevervollständigung schon direkt in den Code ergänzt bekommt und man sie nur übernehmen muß - was erstaunlich gute Ergebnisse bringt, auch etwa zum Beispiel beim Einfügen von Kommentaren, die der Copilot erstaunlich gut voraussagt.
Allerdings ist VSCode halt nicht für VBA gedacht (obwohl, sag niemals nie: https://marketplace.visualstudio.com/items?itemName=local-smart.excel-live-server).

Eine echte Hilfe bei VBA-Entwicklung ist MZTools, wenn Du Deinen Arbeitgeber zu einer wirklich preiswerten Lizenz bewegen kannst. Damit spart man enorm viel Zeit, ganz ohne KI.

Also, die Frage, die Du Dir selbst stellen mußt: Bin ich auch nach dem Praktikum an VBA-Entwicklung interessiert?
Ansonsten ist es eher nicht zielführend, sich mit dem Thema näher auseinanderzusetzen. Also für Dich.
Wenn Du Dir dagegen eine Zukunft im Unternehmen vorstellst, nach dem Praktikum, mit der gleichen Tätigkeit, dann solltest Du in jedem Fall zunächst VBA-Grundlagen lernen, dann im Fall von Access auch Datenbankdesign und SQL sowie das Lernen des Access-Objektmodells, bei dem vor allem die Online-Hilfe mit F1 sehr weiterhelfen kann (auch wenn sie oft besch..eidene Codebeispiele zeigt).

Der nächste Schritt wäre dann Backend: Willst Du das Backend selbst weiterentwickeln? Dann ist vor allem das Lernen von Datenbankdesign und SQL im Allgemeinen wie im Besonderen mit PostgreSQL notwendig. Vielleicht kommst Du auch gleich zu SQL Server, was sich im Zusammenhang mit Access eher anbietet und keine Performance-Probleme hat. Die man mit PostgreSQL vielleicht irgendwie lösen kann, aber es ist dennoch eher eine Datenbank, die auf dem Markt nicht so sehr verbreitet ist. Die Hauptdatenbanken sind Oracle und SQL Server, dann noch MySQL (=MariaDB heute) und da sollte man sich schon spezialisieren. Denn jede bringt eine ganze Menge eigene Spezialitäten mit, die oft nicht kompatibel sind mit Konkurrenten. Meine Präferenz ist ganz klar SQL Server, aber das ist nur meine Meinung. Mit einer Version, die mittlerweile auch auf Linux läuft sowie mit Azure und damit SQL Server in der Cloud deckt SQL Server halt alle Bereiche ab. On Premise, Cloud, Webdatenbank, und mit Express auch noch eine kostenlose Version. Mit Developer Edition auch eine Vollversion nur zum Entwickeln kostenlos für jeden.

Also: Was erwartest Du von Deiner beruflichen Zukunft, in welche Richtung willst Du gehen, und willst Du bei dem Unternehmen bleiben oder nachher etwas ganz Anderes machen? Wenn Du Dir darüber im Klaren bist, kannst Du eine entsprechende Entscheidung treffen. Dazu mußt Du hier natürlich nichts schreiben (würde ich auch nicht machen, the Internet never forgets). Das ist alles für Dich zum Überlegen im stillen Kämmerlein.

Gruß

Christian

[DF6GL]

Hallo,

kurze Anmerkung zur ursprünglichen Frage:



Code fürs Doppelklicken auf den Namen des Endlosformulars:  ID-Feldes:

Private Sub partsid_DblClick(Cancel As Integer)
    Dim id As Integer  Long
    id = Me![partsid]
    DoCmd.OpenForm "Bauteil Info 2", , , "detailsid = " & id
End Sub

DF6GL
Franz