Access-o-Mania

(1) Gibt es in Access die Möglichkeit, einen Zoom einzurichten? Beispielsweise analog der Möglichkeit in Excel, mit dem Mausrädchen die Größe herauf oder herunter zu drehen? Wenn nein, welche Alternativen sind empfehlenswert?

(2)  Gibt es die Möglichkeit, in einem HF zwei UFOS einzubinden, die neben einander stehen und auf der selben Abfrage basieren und auch immer gemeinsam synchron die selben Datensätze anzeigen? Simuliert werden soll die von Excel gewohnte "fixierte Spalte". Dabei bleibt eine Spalte immer sichtbar, auch wenn die anderen Spalten nach rechts raus gescrollt werden.

Carl

Zoomen außerhalb der Seitenansicht kann man käuflich erwerben - siehe ShrinkerStretcher (http://www.peterssoftware.com/ss.htm) - oder müsste selbst programmiert werden. Leute mit schlechten Augen können auch die Bildschirmlupe von Windows verwenden.

In einer Datenblattansicht lassen sich auch Spalten fixieren. Will man mehr (z.B. in einer Endlosformulardarstellung), müsste man sich das Feature auch selbst programmieren.

(zu 2) macht man das am Besten, indem man HF und beide UFOS über die ID verbindet?

Siehe: Fixieren der Felder in einer Access-Datenblatt (https://support.office.com/de-de/article/fixieren-der-felder-in-einer-access-datenblatt-1b88e219-bd8d-44da-a406-79dac4e4af2d)

Hallo,
im Zusammenhang mit dem anderen Thema von Dir
http://www.access-o-mania.de/forum/index.php?topic=23551.msg138342;topicseen#new (http://www.access-o-mania.de/forum/index.php?topic=23551.msg138342;topicseen#new)
wollte ich nur erwähnen, dass sich das mit der angedachten Umstrukturierung erledigt hätte.
Mann könnte die 21 Datumsfelder in 2 Unterformularen (Datumsfeld 1-11 und dann 12-21) zusammen mit einem hafo für die Kopfdaten schön übersichtlich anzeigen, alle 30 Felder der Kopfdaten und alle Datumsfelder auf einen Blick, ohne auch nur ein cm zu crollen. Und Programmierungen von fixierten Spalten braucht es dann ohnehin nicht mehr.

Ja, das klingt interessant.

Meine Vorgabe ist, dass es sich anfühlen soll wie in Excel. Es sollen ja noch mehr solche Formulare entstehen und sie sollen sich möglichst wie Excel anfühlen. Ich kann das auch nicht ändern.

Carl

Hallo,
das ist dann kein Excelaussehen. Ich auch nicht mehr weiter helfen, meine Vorschläge setzen eine Umstrkturierung voraus, da bleibt von Excelsicht nicht mehr übrig..
Siehe Dein anderes Thema (Statistik).

Ich muss dieses Excel-ähnliche einhalten, das iss ne Vorgabe. Die brauchen Ruhe und Gleichförmigkeit.

Was zum Beispiel bei Excel auch geht ist, dass man in einer Zelle einen Standardwert berechnen lassen kann, aber mit der Eingabe eines anderen Wertes diese Vorgabe überschreiben kann.

Zum Beispiel kann ich in Access dem MA ein neues Datum vorschlagen (schätzen) mit:


=DatAdd("m";4;(DatAdd("t";+14;[datevon])))


aber man kann dann in dem selben Feld kein anderes Datum überschreibend eintragen, wenn einem dieser Vorschlag nicht gefällt.

Carl

Hallo,
das geht mit Access natürlich auch, entweder als Standardwert, oder per VBA.
Per VBA so:
Me.Datumsfeld = DateAdd("m",4,(DateAdd("d",14,Me.[datevon])))
Und das kann dann beliebig überschrieben werden.

Was Du machst, ist einen festen Wert zuweisen, Du bringst da einiges durcheinander.

Wenn man das Datenmodell mal konsequent normalisieren/umstrukturieren würde, würde kein Mensch mehr nach Excelaussehen verlangen.  ;D

hm ...

Hallo,

Zitathm ...

und das heißt was ?
Einfach hm ... ist ja bedeutungslos.

Also Du meinst, die 21 Felder in eine extra Tabelle legen? Ich habe das schon mal vorher gemacht und hatte Huddeleien beim synchronen Anlegen der Datensätze.

Außerdem soll nach den 3 Jahren eine Routine zum anonymisieren der DS benutzt werden, die gewährleistet, dass bestimmte Felder gelöscht, andere aber für die Statistik behalten werden. ich befürchte, dass es hier zu Verwicklungen kommen kann.

Mal ne Frage: Soll der Code hier in die zugrundeliegende Tabelle oder formularseitig?

Me.Datumsfeld = DateAdd("m",4,(DateAdd("d",14,Me.[datevon])))


Hallo Carl,

Zitatich befürchte, dass es hier zu Verwicklungen kommen kann.

Mit einem guten Datenmodell, dessen Entwicklung du vehement ablehnst,
kann es normal eigentlich keine Verwicklungen geben. Das ist der Vorteil
gegenüber Excel.
gruss ekkehard


P.S.: Exceltabelle (Sheet) <> Accesstabelle (Table)

Hallo,

ZitatSoll der Code hier in die zugrundeliegende Tabelle oder formularseitig?

Das kann nicht in einer Tabelle sein, das ist VBA Code der niemals in einer Tabelle sein kann.

ZitatAlso Du meinst, die 21 Felder in eine extra Tabelle legen?

Irgendwie komme ich mir vor, als rede ich gegen eine Wand.
Wie bereits mehrfach gesagt, nicht 21 Felder, sondern ein Feld in 21 Datensätzen mit einem Fremdschlüssel zu den Kopfdaten. Da sind Probleme mit dem synchronen Anlegen völlig ausgeschlossen. Das wird auch keine 1:1 Beziehung wie von Dir mal geplant, sondern muss 1:n werden.
Aber das habe ich alles schon mal erklärt.

Wenn Du wirklich eine Datenbank nach den Regeln machen willst, so solltest Du Dich dringend mit den Grundlagen zu relationalen Datenbanken beschäftigen, das wäre unerlässlich.
Hier noch 2 Links dazu (möglicherweis habe ich die aber schon mal gepostet).
https://www.hdm-stuttgart.de/~riekert/lehre/db-kelz/
https://www.access-tutorial.de/

Zitat von: Beaker s.a. am Oktober 05, 2018, 16:47:07
Hallo Carl,

Zitatich befürchte, dass es hier zu Verwicklungen kommen kann.

Mit einem guten Datenmodell, dessen Entwicklung du vehement ablehnst,
kann es normal eigentlich keine Verwicklungen geben. Das ist der Vorteil
gegenüber Excel.
gruss ekkehard


P.S.: Exceltabelle (Sheet) <> Accesstabelle (Table)

Ich schätze dass Du Recht hast Ekki, aber ich vermute, dass ich es auf eigene Kraft nicht weiter hin bekomme. Zudem habe ich die Vorlage, dass es wie Excel aussehen soll. Zumindest bis es eingelebt ist, dann geht sicher mehr.

Ich habe keinen Zweifel, dass Klaus's Lösung besser ist.

Carl

Zitat von: MzKlMu am Oktober 05, 2018, 17:42:56
Hallo,

ok, ich weiß schon, 21 DS in der Vorgangstabelle. Damit wäre auch eine Änderung der Konstante "21" kein Problem mehr.

Aber ich würde durch einander kommen. Ich kann einfach nicht allein weiter.

Ich denke man muss schrittweise lernen. Die nächste DB wird besser.

Carl

Hallo Carl,

ZitatIch denke man muss schrittweise lernen.

Ja sicher, haben wir alle.
Aber du musst am Anfang anfangen, und das ist nun mal die Datenmodellierung.
Und hier werden auch zwei Tabellen zu wenig sein nach dem was ich an
Entitäten aus deinen Beschreibungen so herauslesen konnte.
Das Helfen wird dann noch erschwert aufgrund der mangelnden Einsicht in die
Hintergründe/Abläufe, die du selber nicht komplett verstehst.
Und diesen ganzen Excelquatsch musst du deinem Auftraggeber ausreden; -
wenn er Excel will soll er Excel verwenden. Vielleicht muss der Anfang sogar
schon dort gemacht werden, indem er seine Prozesse mal analysiert und überdenkt.

gruss ekkehard

ZitatZudem habe ich die Vorlage, dass es wie Excel aussehen soll. Zumindest bis es eingelebt ist, dann geht sicher mehr.

Dafür wird man gut bezahlt?
Dann kann man den Usern einschließlich Chef ein Excelblatt vor die Nase zum Angucken halten, bei  Bedarf die Daten aber in der Datenbank verwalten, sofern nötig. macht dann etwas mehr Arbeit bei erhöhten Anforderungen an den Entwickler.

Zitat
Die nächste DB wird besser.

Aus Gewohnheitsbildung sicher nicht.
Gleichlautend solltest Du für diese DB Schmerzensgeld parat halten, sofern ein Nächster diese anfassen muss.