Abfrage - nur Felder mit Werten

[FrankiLi]

Hallo zusammen,

kurze Frage, ich hoffe ich stehe nur auf dem Schlauch:
Ich will über eine Abfrage nur die FELDER sehen, die bei mindestens einem der enthaltenen Datensätze auch einen Wert beinhalten. Anders rum: Alle Felder/Spalten, die nicht komplett "leer" sind.

Danke und Gruss
Frank

[MzKlMu]

Hallo,
kannst Du das mal genauer beschreiben ?
Einerseits sprichst Du von Datensätzen, andererseits von Spalten.

Wie genau sieht denn die Tabelle aus ?
Wenn es in dieser Tabelle Felder gibt die alternativ ausgefüllt sind (mal Feld1, mal Feld3, mal alle), so würde das eher auf eine fehlende Tabelle hinweisen.

[FrankiLi]

Ja, es sind auch einmal Datensätze und einmal Felder.

Felder: Artikelnr / Farbe / Größe
Manche Artikel haben eine Farbe, manche eine Größe und manche beides.
Auswahlabfrage nach verschiedenen Kriterien bringt mal Artikel mit Farbe, mal mit Größe, mal mit beidem.
In dem Fall, dass bei der jeweiligen Abfrage keine Artikel mit Größe enthalten sind, soll Feld Größe erst gar nicht angezeigt werden (ja, man könnte es einfach aus der Abfrage entfernen, aber das Ganze ist ja viel komplexer und soll auch dynamisch funktionieren)

[MzKlMu]

Hallo,

aber das Ganze ist ja viel komplexer und soll auch dynamisch funktionieren)

daher halte das Vorhaben in der Form für unbrauchbar. Das Datenmodell ist ungeeignet. Es ist auch gar nicht so einfach Spalten je nach Inhalt dynamisch anzuzeigen/auszublenden. Die Merkmale sollten immer in einer Spalte stehen und in einer weiteren Spalte dann der entsprechende Wert.
In dem anderen Beitrag von Dir
http://www.access-o-mania.de/forum/index.php?topic=21849.msg125544#msg125544
Beitrag #3 habe ich eine ähnliche Beispieldb eingestellt. Auf diese bist Du aber leider nicht weiter eingegangen. Setz dich mal damit auseinander, es ist zu 100% auf Deine DB übertragbar.
Also so:

Code [Auswählen] Erweitern

Artikelnr / Merkmal / Eintrag
   1         Farbe      blau
   1         Größe      52
   2         Farbe      rot
Statt der Merkmale im Klartext, stehen da in der Tabelle natürlich nur die entsprechenden Schlüsselzahlen (Fremdschlüssel).

Darstellung mit Hauptformular (Artikel) und Unteformular (Merkmale)
Es werden im Ufo automatisch nur die zum Artikel passenden Merkmale und Werte angezeigt. Dazu ist kein Buchstabe zu programmieren.

[FrankiLi]

Hallo Klaus,

naja, ich habe meine anschließenden Tests/Erkenntnisse nicht kund getan, aber mich doch für Deine Hilfe und die Beispiel-db bedankt..

Ich verstehe das absolut und würde auch sofort so verfahren, aber folgendes spricht in dem konkreten Fall dagegen:
- Schnittstelle zu SharePoint, hier gehen Beziehungen verloren, erst recht bei der Weiterverarbeitung in Access
- Massenänderungen, zB werden auf einen Rutsch 2.000 Artikel erfasst, die alle möglichen Attribute haben, aber alle die Farbe weiß. Mit Feldern pro Attribut einmal "weiß" reinschreiben, runterziehen (in SP-Listen) und fertig, quasi Excel-like. Geht natürlich auch per Aktualisierungs- oder hier Anfügeabfrage, aber das kann hier kein Anwender und dafür eine Logik einzurichten wäre ja wieder Access-Intern begrenzt.
- Der Output Richtung ERP findet ohnehin flach statt per csv und hartem Matching von Feld zu Feld. Vom "eigentlich richtigen" Datenmodell dann wieder zurück zu "flach" erscheint mir auch etwas mit der Kirche ums Dorf

Ich machs mir ja mitnichten leicht, am Schluss gehts um einen Weg, der im Doing mit möglichst wenig Aufwand funktioniert, auch wenn ich strukturell leider Abstriche machen muss.

Gruss
Frank

[MzKlMu]

Hallo,
ich kenne mich zwar mit SharePoint nicht aus, kann mir aber nicht vorstellen, dass hier ein normalisiertes Datenmodell schädlich wäre bzw. nicht möglich.

aber das kann hier kein Anwender und dafür eine Logik einzurichten wäre ja wieder Access-Intern begrenzt.

Die Anfügeabfragen wäre das richtige Mittel. Das müsste man für den Anwender programmieren. Und wo siehst Du da eine Begrenzung durch Access ?

Abgesehen davon, ist es schlichtweg unmöglich in eine Abfrage Felder Datensatz abhängig aus bzw. einzublenden. Wenn in einem DS Farbe Rot vorhanden ist, dann ist die Spalte in allen DS zu sehen, egal ob vorhanden oder nicht.

[FrankiLi]

Mit "begrenzt" meine ich, dass sich das in Access abspielen müsste und, wenn SP Frontend ist, dann so nicht funktioniert - es sei denn, das macht jemand, "der sich in Access auskennt" und quasi im Backend, aber dazu kommt das viel zu oft vor.

PS:

Wenn in einem DS Farbe Rot vorhanden ist, dann ist die Spalte in allen DS zu sehen, egal ob vorhanden oder nicht.

Das ist klar. Mir gings um den Fall, dass "rot" im Feld "Farbe" bei der Abfrage gar nicht enthalten ist, quasi die "Farbe" hier gar keine Rolle spielt.

PPS:

ich kenne mich zwar mit SharePoint nicht aus, kann mir aber nicht vorstellen, dass hier ein normalisiertes Datenmodell schädlich wäre bzw. nicht möglich

Ich mir "eigentlich" auch nicht, aber immerhin ist SP ja kein Datenbank-Programm, soviel muss man wohl MS dann doch zugestehen Dort funktionieren zwar Relationen über Nachschlagefelder, aber das ist ziemliches Gefummel, wie ein anderer User hier schon angemerkt hat.

[MzKlMu]

Hallo,
dazu könnte man ein extra Access Frontend erstellen das diese Datenmanipulationen/Anpassungen vornimmt. Das muss nicht in SP gemacht werden.

[FrankiLi]

OK, aber zwei Frontends sind ja auch wieder schwierig, die Anlage muss rückfragearm flutschen.

Wobei, da fällt mir was ein, was so ein zusätzliches Frontend zusätzlich rechtfertigen könnte, und wirklich massiv Zeit sparen:
Das "Ausmultiplizieren" von Varianten. Hatte ich im anderen Thread schon mal kurz erwähnt:
Ich habe einen Grundartikel, den es in 10 Farben und 8 Größen gibt (nur ein Beispiel, bei uns tlw viel komplexer).
Aufgabe: Die bestellbaren Varianten (idr gibt es jede Kombination, also keine Ausschlüsse) daraus generieren, jede Variante ist ein Datensatz/Artikel.

Mir ist da in Access noch nichts zu eingefallen, was aber wohl eher an mir liegt (und auch daran, dass ich gerade an 17 Baustellen parallel arbeite). Dir bestimmt, oder ?

[MzKlMu]

Hallo,

Die bestellbaren Varianten (idr gibt es jede Kombination, also keine Ausschlüsse) daraus generieren, jede Variante ist ein Datensatz/Artikel.

Das geht mit Access völlig problemlos mit einer Abfrage die alle 3 Tabellen (Grundartikel, Farbe und Größe) enthält. Ohne Beziehungen.
Die Abfrage wird zu einer Anfügeabfrage gemacht, die die vorgefertigte Variantentabelle füllt. Der in dieser Tabelle vorhanden Autowert ist dann die Artikelnummer der Variante.
Im Anhang ein einfaches Beispiel. Die Variantentabelle ist leer.
Klicke die Abfrage (VariantenErstellen) doppelt und die Variantentabelle ist fertig. Es werden nur die Schlüsselfelder gefüllt. Die Abfrage "AbfrageMitKlartext" zeigt dann die Varianten mit Klartext. Das geht auch mit 1000enden von Grundartikeln sehr schnell.
Habe das gerade mal spaßeshalber getestet, 10000 Grundartikel mit 200000 Varianten dauert ca. 8 Sekunden.

Beispiel anbei, mit leerer Variantentabelle.

[FrankiLi]

Super, Klaus! Herzlichen Dank !!

[FrankiLi]

Hallo,

nochmal ein Problem, das sich vielleicht erst aus der Notwendigkeit ergibt, dass ich halt 1:1 arbeiten muss:
Der Beschreibungstext soll sich aus verschiedenen Felder zusammensetzen, allerdings nur aus denjenigen, die einen Wert beinhalten. Beispiel: Artikel xy, Farbe: weiß, Größe: 180 - ist aber Größe=Null, nur: Artikel xy, Farbe: weiß

Ist das irgendwie machbar ohne Code?

Aus Interesse: Mit einem relationalen Aufbau mit Schlüsseltabellen etc. wäre das einfacher?

Danke vorab.

Gruss
Frank

[Beaker s.a.]

Hallo,
Um noch mal auf das OP einzugehen

Ich will über eine Abfrage nur die FELDER sehen, die bei mindestens einem der enthaltenen Datensätze auch einen Wert beinhalten. Anders rum: Alle Felder/Spalten, die nicht komplett "leer" sind.

Eine Abfrage (SQL-String) lässt sich ja auch mit VBA zusammenstricken.
Ob es besser geht und/oder es an der Performance scheitert weiss ich nicht,
aber meine Idee wäre

- die Feldliste durchlaufen
- prüfen ob DCount > 0
- wenn ja Feldname an SQL-String anhängen
- am Ende den String vervollständigen (WHERE, GROUP, was weiss ich)
- mit dieser Abfrage weiterarbeiten

gruss ekkehard

[MzKlMu]

Hallo,

Mit einem relationalen Aufbau mit Schlüsseltabellen etc. wäre das einfacher?

ja, da gäbe es das Problem nicht, denn es gäbe keine leeren Felder. Es gibt ja zu jedem Artikel nur die Merkmale/Attribute die auch für diesen Artikel zutreffend sind, also gibt es keine leeren Felder.
Das ist aus meinem Beispiel (Werkzeuge) aus Deinem anderen Thema erkennbar.

Zu Deinem 1:1 Modell.
Offensichtlich hast Du ja auch in der abhängigen 1-Tabelle leere Felder. Daher halte ich diese zusätzliche 1-Tabell für überflüssig. Du kannst auch die Felder direkt in die Artikeltabelle einfügen. Du hast keinen Vorteil durch die beiden 1:1 verknüpften Tabelle. Auch der Speicherplatzbedarf ist größer durch die zusätzliche Verwaltung einer weiteren Tabelle.
Die zusammengesetzte Beschreibung erhältst Du bei Deiner Umsetzung so:

Code [Auswählen] Erweitern

SELECT Artikel, [artikel] & IIf([farbe] Is Null,""," Farbe:" & [farbe]) & IIf([Größe] Is Null,""," Größe:" & [Größe]) AS Beschreibung
FROM GrundartikelHier werden die Worte Farbe und Größe im Beschreibungstext aufgeführt. Je mehr Merkmale um so umfangreicher wird die Formel.

Wie viele Merkmal (Farbe, Größe etc.) gibt es denn ?

[DF6GL]

Hallo,

vielleicht führt sowas zum Ziel:

SELECT ("Artikel: " + [artikelnr] + "  ") & ("Farbe: " + [farbe]) + " ") & ("Größe: " +[Größe]) AS Beschreibung
FROM Grundartikel