Office: (Office 2013) Datensatzmarkierer

Hallo zusammen!
Gern würde ich - per Datensatzmarkierer - in einer Liste mehrere DS (Zeilen) vom User selektieren lassen.

Die DS stehen allerdings NICHT zwangsläufig direkt untereinander

So wie ich es im Moment sehe, kann man aber nur dann mehrere DS gemeinsam markieren, wenn genau dies aber der Fall ist.

Sehe ich das richtig, oder habe ich da eine Tastenkombination übersehen?

Gruß OD

:)

 

Windowsüblich ist es, zusammenhängende Bereiche mit gedrückter Umschalttaste (Shift) auszuwählen, Einzelzusammenstellungen dann mit gedrückter Strg-Taste (Ctrl).

 

Ja, Du siehst das richtig.

 

Hallo Nouba! Wenn schon zwei das so sehen, ist wohl etwas dran *wink.gif*
Schade an sich. Sehe auch keinen Grund dafür...
Gruß OD

 

Hi OD,

wenn ich sowas selektieren möchte, dann bekommt meine Tabelle ein Feld tblSelected. Damit kannst Du dann die DS über ein Kästchen entsprechend auswählen lassen.
Mal so als Workaround.

VG
trekking

 

...der zugrunde liegenden Datenquelle generell ein zus.Feld zu spendieren, nur um (wenn überhaupt) einmalig während eines Bestellvorganges eine selektive Auswahl treffen zu können, erscheint mir nicht angemessen.
Sicher, du hast recht, es wäre ein workaround, aber ich hätte gern eine bessere Lösung.. die kann ich aber selbst noch nicht bieten.
Bin noch am denken :-)
Gruß OD

 

...ich habe 2 tbl die in einer 1:n zueinander stehen.

Sie sind über das in beiden tbl vorhandene Feld [Rechnungsnummer] miteinander verknüpft.

Es gibt in der "n" kein Feld (Auto-Wert, Primärschlüssel) etc. mit dem sich ein DS eindeutig identifizieren lässt, weil dies bislang nicht notwendig war.

In Bezug auf mein Problem des selektiven Markierens wäre das natürlich von Vorteil.

Ich könnte mir vorstellen das Access "irgendwo" so eine eindeutige Zuordung verwaltet, um systemintern bestimmte Funktionalitäten (bspw. das Löschen eines DS durch vorheriges Markieren mit dem Datensatzmarkierer) zu gewährleisten.

Vielleicht könnte man darauf zugreifen, wenn es das gibt...???
OD

 

Hallo,
ich halte das zusätzliche Haken Feld zu Selektion nicht für einen Workaround, sondern für eine einfache und elegante Lösung.
Das Feld kann problemlos über einen Button aus/eingeblendet werden und nimmt kaum Platz weg. Mann kann auch im Formularkopf ein Hakenfeld unterbringen, das das Hakenfeld in Datensätzen ein/ausschaltet und auch noch alle anhakt oder Haken wieder entfernt. Alles andere ist ziemlich aufwendig und halte ich für die schlechtere Lösung.

Und das wichtigste Argument für das Hakenfeld ist die sehr einfache Weiterverwendung der angehakten DS. Mit der Selektion soll ja was passieren.

Das ist durchaus Gang und Gäbe und findest Du z.B. auch im Mailprogramm von Web.de.

 

Hallo!

Ein Feld in der eigentlichen Datentabelle zum Kennzeichnen einer Markierung kann in einer Mehrbenutzerumgebung schnell schief laufen, falls mehrere Anwender in dieser Tabelle Datensätze markieren.
Ich verwende für eine Mehrfachauswahl in einem Endlosformular eine Temp-Tabelle, die nur von der jeweiligen Instanz der Anwendung genutzt wird und speichere die eindeutige Kennung vom Datensatz in dieser ab.
Anm: eine eindeutige Kennung muss es (zumindest für mich) sowieso für jeden Datensatz geben, sonst passt das Datenmodell nicht. (Darf auch ein Mehrfelder-Index sein.)

Die Auswahl zeige ich im Endlosformular in einer Checkbox. Die Daten dafür kommen aus einem Join der Datenquelle für das Endlosformular.

Prinzip:
Code:

mfg
Josef

 

\@GpsWanderer
Danke für das Wort Elegant *Smilie

@josef
Du hast recht, wenn die Tabellen gebunden sind ist das ein Problem. Da hatte ich aus dem Grunde nicht dran gedacht, da ich immer mit Disconnected Recordsets arbeite die da volkommen schmerzfrei in der Mehrbenutzerumgebung sind *Smilie
Eine Zwischentabelle ist auch eine Lösung aber die Disconected Recordsets finde ich an der Stelle für Mehrbenutzerumgebungen unschlagbar.

Viele Grüße
trekking

 

Hallo,
... ich verwende für solche Aufgaben ein Listenfeld mit Mehrfachauswahl.
Z.B. offene Rechnungen von verschiedenen Kunden auswählen oder dergl.
Man kann auch 2 Listfelder für solche Aufgaben verwenden... von Liste zu Liste verschieben.
Denke, es gibt eine reiche Auswahl an Problemlösungen dieser Art.

 

\@trekking:

Disconnected Rs nutze ich auch gerne.

Wegen dem "unschlagbar"
Eine Weiterverarbeitung wie
Code:

ist bei disconnected Recordsets auch etwas schwierig. *wink.gif*

mfg
Josef

 

\@Josef
Da ich immer ungebunden arbeite benutze ich die DCRS in der Regel für die Anzeige von Datenblättern, Listenfelder oder Kombiboxen. Mittlerweile auch des öfteren als Ersatz für lokale Tabellen indem ich diese als Objekt in einer Klasse speichere.
Inserts mache ich in der Regel an der Stelle nicht mit dem Disconnected Recordset. Meist mache ich INSERTS im ungebundenen Formular über SQL mit einer speziellen Routine und meist in einer Transaktion sofern mehr wie eine Tabelle in Eingriff ist *Smilie
Deshalb für mich unschlagbar in der Mehrbenutzerumgebung.

Die Aufgabe von Onkel Dittmeyer liese sich aber sicher mit dem zusätzlichen Auswahlfeld und einem Disconnected recordset m.E. nach sehr gut lösen.

Grüßle trekking

 

Hallo zusammen!

Vielen Dank erstmal für die zahlreichen Reaktionen, die - auch untereinander zum regen Austausch geführt haben.

@zus. Auswahlfeld (.. in der der recordsource)
Dass ich dies nicht für optimal halte, erwähnte ich schon.
In eine Datentabelle gehören meins Erachtens Daten.
In der Regel in Normalform, und keine Objekte die zur Steuerung/ Funktion eins FE notwendig sind.
Ob man das so hält, bleibt natürlich jedem selbst überlassen.
Natürlich ist eine solche Lösung bequem und funktionsfähig,
doch ich möchte es halt anders lösen (wenn möglich)

Als Ausblick kann ich davon berichten, das bei grooooßen Tabellen.
eine Lösung mit extra Feld ein no go wäre.
Wohlgemerkt, große, sehr große Tabellen, Mit denen ich nichts zutun habe(n will).
Es sind (Oracle)-Tabellen mit einigen Milliarden! DS die im bargeldlosen Zahlungsverkehr eingesetzt werden.

In der Abt sind u.a.Leute angestellt die (fast) den ganzen Arbeitstag nichts anderes machen als DEN optimalen SQL-String zu entwerfen, der die Daten für die jeweilige Anfrage der Statistiker zusammenstellt.

In Anbetracht der Datenfülle, der benötigten Rechenzeit, des im Grunde nicht vorhandenen Zeitfensters wegen des 24/7 Betriebes, wird dort um jedes Feld gefeilscht.
Mir ist klar, dass das andere Maßstäbe sind.
"Big Data" wäre auch nicht mein Ding, weil die Jungs natürlich nichts mit FE & Co zutun haben. Das aber finde ich gerade interessant, weil man hier seine Kreativität vielfältig einsetzen kann.
..das nur mal nebenbei

Was mein Problem angeht, bin ich jetzt mit meiner Überlegung soweit,
das ich zur "eindeutigen" Identifizierung eines DS den "current record" auslese, und (vermutl.) in ein Array schreiben lassen, sofern er Teil einer Mehrfachmarkierung geworden ist.
Da die Markierung quasi eine Momentaufnahme ist reicht dieser Zähler.
Das bei Änderung der Sortierreihenfolge, Hinzufügen/Löschen eines DS sich der current record ändert ist dafür egal.

Mit Hilfe dieses Arrays kann ich dann alle ausgewählten DS erfassen und weiter bearbeiten.
Ich erspare mir (bis hierhin) also das zus. Feld, die temp-Tabelle etc.

Ungelöst ist nun noch die Anforderung, dass ich dem User natürlich zeigen möchte, welche DS er ausgewählt hat. Sie sollen sich optisch von den nicht ausgewählten DS unterscheiden.

Hierzu würde ich die bedingte Formatierung einsetzen wollen. Natürlich wieder ohne zus. gebundenes Feld (...was auch hier die Sache natürlich wiederum viel einfacher machen würde Grrr.. :-)

..mal sehen..
Gruß OD

 

Hi OD,

zu den zustälichen Auswahlfeldern hast Du was entscheidendes vergessen. Es wiederspricht an der Stelle nicht der Normalisierung, da es ein eindeutiges Attribut ist. Also Feld gewählt oder nicht. Wie wenn Du einen Datensatz nicht wirklich löschst, sondern nur ein Feld in der Tabelle hast, das 0 oder -1 sein kann und Du den DS nur auf gelöscht "setzt".

Die wesentliche Crux an der Sache ist, dass Du nicht erwähnt hast, dass Deine Daten aus einer DB kommen auf die Du keinen Einfluss hast.(Oder ich habe es überlesen) Es wäre nett gewesen wenn Du das erwähnt hättest, dann hättest Du bestimmt andere Vorschläge erhalten und nicht eine unnötige Diskussion angestoßen. *frown.gif*

Wenn es denn Mehrfachauswahl sein muss, warum dann kein Listenfeld. Damit geht das doch recht einfach. Eventuell auch ein ListView, das ist auch noch flexibler.

Denkbar wäre auch, dass du ein Form (wie in Excel, geht auch in Access) nimmst und dort das Listenfeld benutzt.

Oder Du verwendest einen Disconnected Recordset und erstellst in diesen nach dem Disconnecten das Auswahlfeld. Den kannst du dann wieder einem Datenblatt (formular mit UF Datenblatt) zuordnen und entsprechend auslesen.

Oder Du nimmst VB.net anstatt Access. Da kannst Du Dir das dann selbst entwerfen.

VG
trekking