Fehler: Dokument hat zu viele Absätze - es muss in mehrere Dokumente ...

[Kadlec]

Hallo ich versuche über eine DB verschiedene Reports zu verteilen.
Bisher gab es Papier nun sollen die Daten in ein Dokument.
Bei einem Vorgang mit 750 Seiten (Report wird eingelesen in eine List und dann in ein RT Feld geschrieben) gibt es nun die Fehlermeldung "Dokument hat zu viele Absätze - es muss in mehrere Dokumente aufgeteilt werden."
Gibt es da wirklich keine andere Möglichkeit?

Ich lese die Seiten komplett ein da es möglich sein muss diese doch noch zu drucken und ausserdem soll das Layout der Daten wie auf dem Papier aussehen.

Boris

[MadMetzger]

Wie wäre es, wenn du das tatsächlich auf mehrere Dokumente verteilst? (Ein 750 S. starkes Dokument wird sicher nicht sehr performant öffnen)

Also du hast ein Hauptdokument je Lauf eines Reports. Als Antwortdokumente hast du dann jeweils die Seiten oder im Extremfall sogar die einzelnen Zeilen.

[WernerMo]

Hallo,

auch wenn es einmal mehr Arbeit ist:

Die Lösung kann nur ein PDF sein, dass dann attached wird.

MfG Werner

[MadMetzger]

Und genau dieses PDF kann erzeugt werden, wenn die Dokumente vorhanden sind. Häufig ergibt sich aus dem vorhandensein der Daten nämlich, dass auch Auswertungen gemacht werden. Und das wird besser ermöglicht, wenn die Daten in einer auswertbaren Form vorhanden sind.

[Kadlec]

Die Daten in ein anderes Format (PDF)...gefällt mir gar nicht.Dabei habe ich zwei Möglichkeiten:
1. Vorgang mit (keine Ahnung) 1-250 Seiten ==> Text in RT Feld
2. Vorgang mit > 250 Seiten in PDF

Wie gesagt gefällt mir nicht aber..wohl keine andere Möglichkeit.
Gibt es da irgendeine Hausnummer bei der ich trennen muss/sollte?

Boris

[Axel]

Die Daten in ein anderes Format (PDF)...gefällt mir gar nicht.Dabei habe ich zwei Möglichkeiten:
1. Vorgang mit (keine Ahnung) 1-250 Seiten ==> Text in RT Feld
2. Vorgang mit > 250 Seiten in PDF

Wie gesagt gefällt mir nicht aber..wohl keine andere Möglichkeit.
Gibt es da irgendeine Hausnummer bei der ich trennen muss/sollte?

Boris

Das würde ich so nicht machen. Entscheide dich für einen Weg und mach's überall gleich. Deine User werden es dir danken.

Axel
 

[atbits]

Hallo das Problem hatte ich auch schon mal, das Problem tritt dann auf meine ich wenn man z.B. per Agent immer ins selbe RTItem reinschreibt.

Versuch mal das rtitem zwischendurch wegzuwerfen, dann das document zu speichern dann ein delete notesdocument (achtung nicht remove sondern delete um es aus dem Speicher zu löschen), dann das Document wieder holen und das darin enthaltene RTItem holen.

Dann in dieses RTItem reinschreiben, dann gehts wieder.

Wenn man schaut erzeugt Notes daraus dann mehrere RT-Felder mit selben Namen, die aber irgendwie wie eines gehandelt werden.

Wenn Du das nicht so machst schreibt er alles in ein Feld und das führt zu Deinem Problem.

Habe leider den Code, wo ich das gemacht habe nicht da - hoffe es hilft trotzdem.

Grüße David

[Kadlec]

David,

das entsprechende doc enthält (lt einerDoppeleintrags-ID) insgesamt 235 items.
Werde aber trotzdem mal in die Richtung experimentieren.

Boris

[koehlerbv]

Bei rund 21.500 Paragraphs ist Ende Gelände in einem Notes RichText Item. Du musst halt aufpassen, dass Du nicht wegen jedem Zeilenumbruch einen neuen Paragraph erzeugst und dass der Speicherinhalt eines Paragraphs unter der 64kB-Grenze bleibt.

750 Seiten halte ich aber in den meisten (! - nicht in allen) Fällen für einen Verlust an Möglichkeiten beim Wechsel von Papier zu elektronischem Dokument. Siehe hierzu meine Vorredner. 750 Seiten Report liest keiner (oder man baut ihn anders auf - als PDF oder Word-Dokument oder ausgedruckt oder what ever), sondern man recherchiert darin. Und dafür muss man doch nicht 750 Seiten (Papier-Äquivalent, nehme ich an) laden ...

Bernhard

[MadMetzger]

Danke Bernhard für deine Fürsprache. In meinen Augen kann sieht die Optimallösung hier (unter Mutmaßung einer Menge von Einzelsätzen)  so aus, dass es je Report ein Dokument gibt und je Datensatz in einem Report ein Antwortdokument zum Report gibt. Wenn dann noch Teilreports oder ähnliches gebraucht werden, kann man ja PDFs aus den Daten generieren. Dazu bieten sich beispielsweise Techniken unter Java wie iText oder FOP (unter Zuhilfenahme von XML) an. Alles andere ist eine unpraktische verelektronisierung von Papier, womit die Daten nicht durchsuchbar und sortierbar blieben.

[koehlerbv]

Hallo Markus,

das war ja eher keine Fürsprache (auch wenn ich diese natürlich sehr gerne geleistet hätte  ), sondern ein Aufbau auf Deinem Beitrag: Irgendwas muss man ja mit diesem Report bezwecken wollen - der soll ja bestimmt nicht nur "einfach so da sein".

Ich sehe also genau die gleichen Alternativen wie Ihr sie schon genannt hat: Will man mit dem Report etwas anfangen, dann muss das Ziel hier genauer benannt werden, um konkrete Vorschläge machen zu können. Will jemand, der Boris beauftragt hat, sein Hirn nicht einschalten und wirklich nur "den 750-Seiten-Report in einem Dokument" haben, dann muss halt der Aufbau des RTIs geändert werden. Da mich das dann aber vermutlich nicht mehr interessiert, sage ich für diesen Fall mal: "Doku lesen und Paragraphs reduzieren".

Boris, sag' an 

Bernhard

[Kadlec]

Hallo Bernhard,

den 750 Seiten Report kann man von der Seitenanzahl nicht reduzieren.
1 Seite ist eine Teilnr. (also 750 Teile) mit den entsprechenden Daten. Hierbei könnte man die Zeilen ansich reduzieren da ich diese 1:1 einlese und einige Leerzeilen vorhanden sind. Andere Reports (ca. 1400 Seiten) könnte man schon von der Seitenzahl reduzieren (nicht alle Teile werden benötigt).
Dann gibt es andere Reports die möglicherweise 1500 Seiten haben die man dann nach einer groben Durchsicht direkt in die Tonne treten kann, es muss aber mal durchgeschaut/gescrollt werden. Diese grossen Dinger sind aber eher die Ausnahmen, die Regel dürfte bei < 50 Seiten sein.

Boris

[koehlerbv]

Boris, ist schon klar. Ich verstehe Dich ja auch. Aber lies bitte mal, was ich geschrieben habe.

Bernhard

[Kadlec]

Hallo Bernhard,

ich steh gerade ein wenig auf dem Schlauch.

Deshalb will ich das ganze (was wir mit dem Report machen) und die Hinweise dazu von hier nochmal zusammenfassen.

Wir haben eine DB in der die Vorgänge getrackt werden.
Dazu bekommen wir heute Papier das in vielen Fällen unnütz ist.
Die Frage die dann kam, können wir das Papier (Kosteneinsparung) einstellen und bzw. wie können
wir die Infos daraus dann den Mitarbeitern zugänglich machen.

Mein Ansatz war dann, ein Antwortdoc. auf den Vorgang, mit einzelnen Werten aus dem Report und dem Report in ein RT Feld.

Der Mitarbeiter soll nun, wenn möglich, direkt mit dem doc der DB arbeiten.
Deshalb bei kleineren Reports wäre es unschön wenn erst eine andere Anwendung Word, Acrobat oder was auch immer, starten würde.
Es soll aber auch möglich sein den Report zu drucken, wird über Word gemacht, vorher kann evt. auch eingeschränkt werden Seite 3-5 Kollege 1, Seite 1 + 2 Kollege 2.
Den ganzen Report auf mehrere Antwort docs verteilen, nun dazu gibt es nicht immer einen Trenner.

750 Seiten halte ich aber in den meisten (! - nicht in allen) Fällen für einen Verlust an Möglichkeiten beim Wechsel von Papier zu elektronischem Dokument. Siehe hierzu meine Vorredner. 750 Seiten Report liest keiner (oder man baut ihn anders auf - als PDF oder Word-Dokument oder ausgedruckt oder what ever), sondern man recherchiert darin. Und dafür muss man doch nicht 750 Seiten (Papier-Äquivalent, nehme ich an) laden ...

Bernhard

Meinst Du hier nur die erforderlichen Daten in die DB zu übernehmen ?? Das wäre natürlich mein erster Ansatz gewesen, die Forderung war aber "...muss genauso aussehen wie auf dem Papier".

Boris