Gibt eine eine Maximalgrenze für .Column?

[Manfred S]

Hallo,
ich lese Daten mittels einer Abfrage über ein Kombifeld zum Befüllen eine Tabelle ein, um diese Daten als Konstanten dann der Serienbrieffunktion verfügbar zu machen.
Klappte mit:

Me!St_Firma = Me!ST_Nutzerwechselberuf.Column(1)
Me!St_Anrede = Me!ST_Nutzerwechselberuf.Column(2)
Me!St_Nachname = Me!ST_Nutzerwechselberuf.Column(3)

und ein paar Zeilen davon mehr bislang auch bestens (AC2000).

Nunmehr hat sich die Anforderung wegen weiterer Daten wie bsp. IBAN, BIC und mehreren Konten im Briefverkehr vergrößert und mit der vorstehend beschriebenen und bislang stets funktionierenden Wahl der Datenbefüllung klappt es nicht mehr mit dem Einlesen weiterer Daten. Es gibt auch keine Fehlermeldung. Die Daten werden einfach nur nicht übernommen und in die Tabelle eingetragen. Ich meine, das bei 50 zu übertragenden Datenfeldeinträgen Schluß ist.    

Entweder habe ich nur nen Denkfehler begangen, aber wenn dem nicht so ist, muss ich mir eben eine andere Lösung einfallen lassen.

Danke für einen Hinweis

Gruß
Manfred S.

[Stapi]

Hallo

Schau mal hier:
http://www.kurt-aus-kienitz.de/knowhow/access/Beispiele/Formulare/KombiUndListen/ListKombiFelder.html

[MzKlMu]

Hallo,
ich versteige mich zu der Behauptung, wer in einer Datenbank Column braucht hat etwas falsch gemacht, oder falsch verstanden. Ausnahmen bestätigen die Regel. 

Die Daten des Kombifeldes kommen ja aus einer Tabelle. Warum kann dann nicht mit einer einfachen Abfrage die Daten des Kombis (eventuell mit einer weiteren Tabelle) angezeigt werden?
Die Abfrage kann auch als Datenquelle für den Serienbrief dienen. Eine zusätzlich zu befüllende Tabelle ist dann nicht notwendig.

Was mich noch zu der Frage bringt, wozu eine Serienbrief? Was kann ein Serienbrief was ein Access Bericht nicht kann?

[69bruno]

@ MzKlMu
als alter Wordnutzer kann ich Dir sagen, dass Word einiges kann, was man in einem Bericht nicht so schnell umsetzen kann.
Natürlich kann der Bericht annähernd alles, was Word auch kann, aber der Aufwand, einen Bericht an Layout-Vorgaben anzupassen ist um ein wesentliches höher ..... 
Versuch doch mal, einen Artikelkatalog in einem Bericht zu erzeugen, der ein Verzeichnis mit Seitenzahlen hat......... Das wird ganz schön knifflig.
In Word ist das ein Feld, wird eingefügt, aktualisiert und fertig.......
Ich nutze Office seit je her mit der Devise, Access ist für Datenhaltung, Excel für Rechenfunktionen und Diagramme, Word für's Briefe schreiben.
Ein ehemaliger Arbeitgeber von mir hat mal Versucht, sich das Firmenschreiben als Layoutvorlage in Ad obe fertigen zu lassen. Die arme kleien Firma, die das versucht hat, musste leider aufgeben..... in Word habe ich das mit damals rudimentären Kenntnissen für ihn erledigen können.

[MzKlMu]

Hallo,
@69bruno
unbestritten, aber meine Forumserfahrung zeigt mir, dass viele die Möglichkeiten eines Accessberichts unterschätzen. Man wechselt dann zu Word nur um mal eine Einladung zu einer Mitgliederversammlung zu erstellen. Nur mal so als Beispiel. Und darum geht es mir.
Daher ja auch die Frage, die etwas anders lauten sollte:

@Manfred S
Warum verwendest Du keinen Accessbericht, statt des Serienbriefs?

[oma]

Hallo,

wer in einer Datenbank Column braucht hat etwas falsch gemacht, oder falsch verstanden.

eine sehr "abenteuerliche" Feststellung

Was kann ein Serienbrief was ein Access Bericht nicht kann?

das ist einfach zu beantworten: oft werden umfangreiche Formatierungen und Gestaltungen aus Word benötigt!

Gruß

[MzKlMu]

Hallo,
@Oma
Du hast ja nicht vollständig zitiert. Das mit den Ausnahmen fehlt ja.
Ich halte aber trotzdem an meiner abenteuerlichen Feststellung fest.
Nenne mir sinnvolle Anwendungen von Column, was man durch Abfragen nicht erreichen kann.
Und das wären dann die Ausnahmen.

Und dass es für einen Serienbrief Gründe gibt ist mir auch klar, daher wollte ich ja wissen, was im vorliegenden Fall der Access Bericht nicht kann.

[Manfred S]

Hallo,
ich möchte weiß Gott keine Grundsatzdiskussion entfachen oder den Stein des Anstoßes dafür geben. Und sicherlich gibt es genügend Argumente für die ein oder andere Lösung oder Wahl der Mittel.

Aber nur zum Verständnis der DB. Selbige beinhaltet u. a. eine Nutzerverwaltung mit Rechteverwaltung und eine umfangreiche Serienbrieffunktion in Gestalt von Briefvorlagen und Textbausteinen.

Zur Rechteverwaltung werden pro Nutzer neben dem DB Zugriff eben auch "Privatdaten" als auch "Firmendaten" in einem Datensatz hinterlegt. Das ist so, weil die Konstanten der Serienbriefe nur mit den Absendedaten eines mit DB Zugriffsrechten ausgestattet Users versehen werden dürfen. Die Briefempfängerdaten und Textbausteine werden Endanwendergerecht völlig sauber und menügesteuert andernorts eingelesen.

Mit der DB lassen sich u. a. eine Vielzahl von Briefvorlagen (und darauf eingebettete Grafiken) mit den Daten eines zuvor ausgwählten Users (Absenderdaten) befüllen. Für private Briefe braucht es  sicherlich keine Steuernummer und deshalb die Vorauswahl der Userdaten aus der Usertabelle mit der Unterscheidung "Privat" oder "Firma" in die Tabelle Briefstammdaten mit der eingangs beschrieben "Wahl" des Programmiermittels.

Und weil die auf die Usertabelle greifende Abfragen "Privatdaten" und "Firmendaten" zwar durchaus mehr als 50 Datenfelder aufnehmen könnten, werden die darüber hinausgehenden Informationen in die Briefstammdatentabelle nicht mehr eingelesen. Habe auch schon als Lösung das Einlesen der Daten in zwei Schritten favorisiert. Bsp. erst die Stammdaten mit der Adresse des Users und dann dessen Bankdaten in einer zweiten Abfrage einlesen. Muss mich da wohl mit abhängigen Kombifeldern beschäftigen. Denn die Stammdaten dürfen bsp. nicht mit den Bankdaten eines anderen Users verkreuzt werden werden.

Gruß

Manfred S.

[MzKlMu]

Hallo,
wenn die Daten für den Serienbrief aus einer Tabelle kommen, dann könnte man doch genau so gut eine Abfrage erstellen, die genau die Daten für den Serienbrief enthält. Ein Word Serienbrief brauch keine Tabelle als Datengrundlage, eine Abfrage erfüllt den gleichen Zweck.

Mit dem Serienbrief bin ich hier überzeugt, daher hatte ich ja auch gefragt.
Mit der Notwendigkeit von Column (noch) nicht.

ich möchte weiß Gott keine Grundsatzdiskussion entfachen oder den Stein des Anstoßes dafür geben.

Auch Grundsatzdiskussionen können hilfreich und interessant sein, auch für mich. Ich lasse mich auch gern überzeugen und gebe es dann auch zu. 

[Stapi]

Hallo

Wäre hier dann nicht auch eine Lösung, wenn man den Serienbrief nicht möchte, alle Notwendigen Daten über eine Abfrage per VBA ein Word Dokument zu befüllen?

[Manfred S]

Die Daten werden mittels Abfrage und VBA weitergegeben und sogar einem Briefcontainer des jeweiligen Empfängers zugeordnet, sprich historisiert. Das ist alles gut.
Es geht hier lediglich darum, aus einer Tabelle User mit vielen Datensätzen einen Datensatz daraus in die Tabelle Briefstammdaten zu übertragen und die Frage, warum dies mit meiner bisher einwandfrei funktionierenden Methode nicht mehr funktioniert. Sprich, Access diese Möglichkeit beim Überschreiten des Einlesens und Übertragens von Datenfeldinhalten von einer Tabelle in eine andere Tabelle limitiert.  Die Tabelle Briefstammdaten dient dann als Datenlieferant für den "Export" nach Word.

[MzKlMu]

Hallo,

Es geht hier lediglich darum, aus einer Tabelle User mit vielen Datensätzen einen Datensatz daraus in die Tabelle Briefstammdaten zu übertragen

Und genau hier müsste man ansetzen. Üblicherweise sollte ja jeder Datensatz des Listenfeldes einen Primärschlüssel haben. Und nur dieser Primärschlüssel wird in die Tabelle Briefstammdaten übertragen , sonst keine weiteren Felder.
In einer Abfrage mit der Tabelle "User" und der Tabelle "Briefstammdaten" hat man alle Felder aus beiden Tabellen zur Verfügung. Speichere diese Abfrage mit dem Namen "qryBriefstammdaten" (z.B.).
Diese Abfrage "qryBriefstammdaten"  dient dann als Datenlieferant für den "Export" nach Word.

Damit kannst Du auf Column ersatzlos verzichten.

[69bruno]

Aber solltest Du den Hinweisen nicht nachgehen wollen und immer noch mit dem Kombifeld arbeiten wollen,
dann lass dir doch mal die columncount-eigenschaft anzeigen (msgbox).
Vielleicht hat ja irgendwo jemand schon die Anzahl der Spalten festgelegt und das müsste geändert werden.

[daolix]

ich versteige mich zu der Behauptung, wer in einer Datenbank Column braucht hat etwas falsch gemacht, oder falsch verstanden. Ausnahmen bestätigen die Regel.

Hmm, aber bestehen nicht Tabellen per Definition aus Rows und Colums? Und die benutz ich zu Hauf in meinen Datenbanken. Ich glaub ich mach da was falsch.

[MzKlMu]

Hallo,
ich habe eine deutsches Access, ich benutze Zeilen und Spalten. 

Meine Aussage sollte man im Kontext des Themas sehen.