Anlage über Abfrageformular öffnen

[KingLoui]

Hallo liebe Access Freunde 
Ich suche nun schon seit einigen Tagen nach einer Lösung meines Problems und bin nun auf dieses Forum gestossen, da scheinbar noch nie jmd. das gleiche Problem wie ich hatte (kann aber auch sein ich bin zu blöd zum suchen  )

Ich bin totaler Access-Anfänger und habe folgendes Problem:

Ich habe eine Access Datenbank erstellt um verschiedene Sammelstücke aufzunehmen. Dabei habe ich eine Tabelle erstellt, welche mit weiteren Tabellen in einer 1:n Beziehung steht. Eine Spalte der Haupttabelle ist ein Anlagenfeld. Für dieses Feld gibt es also keine gesonderte Tabelle. Wenn ich nun einen neuen Datensatz speicher (über ein Formular namens "Sammelstück hinzufügen"), habe ich die Möglichkeit in das Anlagenfeld eine Anlage einzufügen, zum Beispiel ein Foto oder ein Beschreibung des Sammelstücks. Die im "Sammelstück hinzufügen"-Formular eingegeben Daten werden dann in die Haupttabelle übernommen.

In der Haupttabelle lässt sich dieser Anhang nun auch normal öffnen, ohne Probleme. Jetzt habe ich eine Abfrage erstellt, welche Daten aus der Tabelle abfrägt. Darauf aufbauend habe ich ein Formular für die Abfrage erstellt, mit verschiedenen Kombinations- und Textfeldern. Ich kann also zum Beispiel nach einem Namen suchen und auf dem Formular werden mir alle Datensätze mit dem entsprechenden Namen angezeigt. Es handelt sich um ein Endlosformular. Allerdings kann ich den Anhang weder in der Abfrage noch im dazugehörigen Formular öffnen. In der Abfrage wird mir lediglich angezeigt, dass dem Datensatz eine Anlage hinzugefügt wurde (Büroklammer mit einer 1 in Klammer) und auf dem Formular wird mir entweder ein .pdf-Symbol angezeigt, wenn ich dem Datensatz eine .pdf-Datei hinzugefügt habe oder eine Vorschau des angefügten Bildes, wenn ich dem Datensatz ein Bild angefügt habe. Ich möchte aber, dass ich auf dem Formular im Detailbereich per Doppelclick auf das .pdf-Symbol oder auf die Bildvorschau, die Anlage im entsprechenden Standardprogramm des Users der Datenbank öffnen kann. In der Haupttabelle lässt sich der Anhang ohne Probleme öffnen. Kann man nicht einfach ein VBA-Code als Doppelclick-Ereignis auf das entsprechende Feld hinterlegen, dass der Anhang geöffnet wird? Ich bin auch offen für andere Lösungen.

Aufjedenfall bedanke ich mich jetzt schon recht herzlich für Anregungen, Lösungsvorschläge und alles was eben kommentiert wird! <3

[MzKlMu]

Hallo,
ich würde auf Anlagefelder grundsätzlich verzichten.
Nimm ein ganz normales Textfeld und speichere darin den Dateinamen (ggf. mit Pfad).
Anlagefelder sind auch wegen des benötigten Speicherplatzes ohnehin nicht zu empfehlen.

Mit einem Doppelklick kannst Du mit FollowHyperLink (VBA) das Bild oder PDF mit dem zugeordneten Programm öffnen.
Achtung: Trotz dem Befehl FollowHyperLink aber kein HyperLink Feld verwenden.

PS:
Gibt es immer nur eine Anlage je Sammelstück ?

[Frank200]

Willkommen im Forum.

Mit den Anlagefeldern kenne ich mich noch nicht so komplett aus, aber vermutlich wird das dort ähnlich gesteuert wie bei den gebundenen Objektfeldern.
Prüfe mal in den Eigenschaften des Formularcontrols des Anlagenfeldes die Eigenschaften Objektaktivierung und Verb. Du findest sie im Tab "Andere".

Ungeachtet dessen ist Klaus' Empfehlung, die Dateien extern zu lagern und nur Dateinamen in der DB zu speichern, wärmstens zu empfehlen.

[KingLoui]

Hallo Klaus, vielen Dank für deine Antwort! Es kann auch mal vorkommen, dass mehrere Anlagen hinzugefügt werden. Die Lösung mit dem Link hatte ich auch schonmal überlegt, hier ist allerdings das Problem, dass mehrere Leute auf die Datenbank zugreifen sollen können und ich mir Sorgen mache, dass es mit der Ablage der Anlagen auf einer Cloud dann Probleme geben könnte.

[MzKlMu]

Hallo,
kein Link, das habe ich auch extra geschrieben, ein ganz normales Textfeld.
Um mehrere Anlagen hinzuzufügen, braucht es eine 3. Tabelle.
Je Anlage ein Datensatz mit einer Beziehung zum Hauptdatensatz.

Wie hast Du Dir die Arbeit mit Access in einer Cloud vorgestellt?
Mit Access kann man nicht mit einer Cloud arbeiten.

In einer Mehrbenutzerumgebung muss die DB in Backend (die Tabellen) und Frontend (alles andere) aufgeteilt werden. Jeder User hat sein eigenes Frontend auf seinem PC. Dazu braucht auch jeder User entweder eine Access Vollversion oder eine Runtime. Lezteres erfordert aber einen hohen Aufwand an Programmierung (VBA) der Benutzeroberfläche.

PS:
Bitte keine vollständigen Beiträge ziteren. In Deiner Antwort in #3 braucht es kein Zitat.

[Hondo]

Hallo,
also ich finde es unglücklich dass MS das Anlagefeld eingeführt hat. m.E. sind das Objekte die nicht in einer Datenbank gespeichert gehören sondern über einen Link referenziert werden sollten.
Und nur 1 Bild pro Sammelstück wird kurz oder lang nicht reichen. Dann lieber gleich eine 1:n verbundene Tabelle mit ID, Fremdschlüssel und Link/Dateiname als Textfeld.

Dadurch bleibt die Datenbank schön schlank und bläht sich nicht auf.
Gruß Andreas

[Bitsqueezer]

Hallo,

@andreas: Weil es so einen Datentyp in nahezu jeder Datenbank gibt, z.B. auch in SQL Server (varbinary(MAX) z.B.). Marketing halt... nur kann man bei SQL Server etwa Filestreams einrichten und damit die Dateien automatisch durch SQL Server selbst auf dem Datenträger lassen statt in der Tabelle.
Für kleinere Dateien oder Vorlagedatei z.B. kann man das auch mal in der Access-Tabelle speichern. Es wird halt nur nicht so genutzt.

@klaus: So pauschal kann man das nicht ausdrücken. Genauer formuliert: Access als Backend in der Cloud ist eher keine gute Idee, aber Access als Frontend kann sehr wohl mit Cloud umgehen - wenn das Backend z.B. ein Azure-SQL Server ist, das funktioniert sehr gut. Filestreams werden auf Azure aber nicht unterstützt.

Zur Runtime: "hoher Programmieraufwand" - nein, nicht wirklich. Man muß nur dafür sorgen, daß Runtime-Fehler immer abgefangen werden, was man ohnehin machen sollte. Ansonsten ein paar gründliche Tests, weil die Runtime manchmal etwas "zickig" ist, aber von "hohem Programmieraufwand" kann man nicht reden.
Im Zuge von Office 365 verliert die Runtime aber immer mehr an Bedeutung, weil die meisten Unternehmen O365 mit Access verwenden und daher eh schon so ziemlich alle Access Vollversion haben.

Gruß

Christian

[KingLoui]

Hallo zusammen,

habe nach langem rumprobieren tatsächlich die Lösung für mein Problem gefunden. Hatte Anfangs in der Abfrage tatsächlich nur das ".FileData" Element des Anlagenfeld mit drin Wenn ich das ganze Anlagenfeld mit rein nehme lässt es sich ohne Probleme im Abfrageformular öffnen.

Trotz allem vielen Dank für eure Hilfe!!!

[knobbi38]

@christian:

Das mit der Runtime sehe ich auch eher wie Klaus. Der Programmieraufwand, insbesondere ein Qualitätstest ist deutlich höher und bei Anwendungen innerhalb der Runtime ist die UI eingeschränkt. Deshalb müssen dafür u.U. bestimmte Funktionalitäten nachprogrammiert werden; Ribbons ggf. neu erstellt werden.
Und was noch zu beachten ist, ist das sich die Anwendung in einer Runtimeumgebung anders verhält, als wenn man nur die Argumente in der Kommandozeile verwendet oder die Dateiendung in *.accdr abändert. Testen kann man wirklich nur in einer "echten" Runtimeumgebung auf einem System, wo keine Access Vollversion installiert ist.

Gruß Ulrich
 

[Bitsqueezer]

Hallo Ulrich,

ja, beim Test gebe ich Dir recht, die Variante mit Umbenennen funktioniert eher mäßig bis gar nicht.
Ribbons aber sind kein Problem, auch wenn man diese selbst in ein eigenes Ribbon einfügen muß, kann man aber komplette existierende Ribbon-Leisten einfach in das Ribbon-XML einbauen, ebenso kann man vorhandene Elemente in eigene Ribbons einbauen, ohne etwas dazu programmieren zu müssen.
Welche UI-Einschränkungen meinst Du? Ich wüßte da jetzt keine, außer daß bestimmte UI-Funktionen natürlich abgeschaltet sind (was auch gut so ist).

Tatsächlich ist der Qualitätstest eher etwas, was in der gleichen Form auch bei jeder Version für die Vollversion erfolgen sollte, denn die Runtime kann keine nicht abgefangenen Laufzeitfehler verzeihen. Wenn man seine Anwendung also als Runtime-Version getestet hat, ist sie auf jeden Fall stabil und korrekt.
Will sagen: Man sollte auch seine Vollversions-Anwendungen mit der Runtime testen, um ein besseres Ergebnis zu erhalten.
So oder so, ein "erheblicher zusätzlicher Programmieraufwand" ist es in keinem Fall.

Gruß

Christian

[knobbi38]

@christian:

Ist schon lange her, aber ich meine mich erinner zu können, daß es etwas mit den Filtern und Sortierungen in der Datenblattansicht zu tun hatte und irgend etwas war auch noch mit der Suchfunktion.
Das die Buildins Ribbonleisten verwendet werden können, ist mir klar, aber ohne weiteres Zutun gibt es erstmal keine.

Leider kann ich das nicht mehr testen, da ich im Moment kein System mit "Runtime-Only" im Zugriff habe.

Gruß Ulrich

[Bitsqueezer]

Hallo Ulrich,

ist es bei mir auch..  (lange her)..
Also bei der Datenblattansicht war meines Wissens kein Problem, aber der Formularfilter existiert nicht in der Runtime. (Weil das für MS wohl eine "Designänderung" darstellt...).
Den kennen die meisten aber eh nicht und wenn sie ihn kennen würden, würden sie ihn nicht verwenden, weil schon nicht ganz trivial zu bedienen. Gemeint ist der Filter, der das Formular klont und alle Eingabefelder sind dann Kriterienfelder zur Eingabe der Filterkriterien, dabei kann man mehrere Tabs öffnen und mit AND/OR usw. als verknüpften Filter verwenden. Das kapiert aber eh kein normaler Access-User, ich kenne niemanden, der das wirklich verwendet (ist ja auch verwirrend, wenn man die normale UI sieht und alles auf einmal ein Filter sein soll).

Ribbons: Ja, ich meinte nur: Es ist kein "erheblicher Programmieraufwand", lediglich eine einmalige Einstellung im XML. Dazu kommt, daß man die gleichen Einstellungen ohnehin macht, wenn man seine Anwendung mit eigenen Ribbons versieht mit "Start From Scratch".

Gruß

Christian