Das Notes Forum

Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: Karotte am 06.05.03 - 15:50:08

Titel: lfd nr für dokumente in ner db
Beitrag von: Karotte am 06.05.03 - 15:50:08
Moins,

wie bekomm ich hin das ich in der Datenbank für Dokumente ne eigene "dok-id" vergeben kann, soll dann so aussehen: 1. Dokument: lfdNr: 2003001, das 11te dann 2003011 etc..

Weiterhin möchte ich dann auch über diese ID's auf das jeweilige Dokument zugreifen, geht das, wenn ja wie?

Titel: Re:lfd nr für dokumente in ner db
Beitrag von: Till_21 am 06.05.03 - 16:07:48
Moins,

wie bekomm ich hin das ich in der Datenbank für Dokumente ne eigene "dok-id" vergeben kann, soll dann so aussehen: 1. Dokument: lfdNr: 2003001, das 11te dann 2003011 etc..

Weiterhin möchte ich dann auch über diese ID's auf das jeweilige Dokument zugreifen, geht das, wenn ja wie?

hi,
bitte suche des forums verwenden, die problematik gab es schon xmal...
ja, du kannst auf die jeweiligen doks zugreifen per 'eigener DocID' - sowohl in SScript als auch in Formel...

gruss
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: klaussal am 06.05.03 - 16:11:48
... forget it, damit handelst du dir nur ärger ein  ;D
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: Axel am 06.05.03 - 20:28:17
Hi,

das Thema hatten wir hier schon ein paar mal.

Schau unter anderem mal hier:
http://www.atnotes.de/index.php?board=9;action=display;threadid=7395;start=0 (http://www.atnotes.de/index.php?board=9;action=display;threadid=7395;start=0)

Ich kann mich klaussal nur anschließen: lass es nach Möglichkeit sein, du handelst dir nur jede Menge Ärger ein, besonders bei Datenbanken von denen mehrere Repiken existieren.

Axel
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: Karotte am 07.05.03 - 10:03:46
hmm diesmal hatte ich nix über die suche gefunden  :'( (ich such ja eigentlich immer)

Das Problem ist ich will ja das die DOC's als Auftrag eingehen und somit ne Auftragsnummer bekommen und diese sollten dann gleich der doc-id sein um mir die zugriffe zu vereinfachen :)

Es wird nur die Datenbank geben also keine Repliken.  Die Frage ist nur wann ich damit anfange...

trotzdem danke
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: Axel_Janssen am 07.05.03 - 10:31:14
die oben geschilderten Probleme sind real.
Was machst Du z.B. wenn user local auf repliken arbeiten?
Bei gelöschten Dokumenten entstehen Lücken. Hatte darüber schon endlose Diskussionen mit kundenseitigen Projektmanagern.

Erste Idee wäre vielleicht, die derzeit aktuelle Nummer in einer Art Konfigurationsdokument abzuspeichern.

Ich halte diesen folgenden Ansatz für vielversprechender:
In querySave

es gibt:
Eine Ansicht mit den AuftragsNr-Dokumenten nach der Auftragsnumemr sotieren (aufsteigend).

du machst
1. die view aus (es gibt:) besorgen.
2. Unbedingt view.refresh()
3. Mit view.getLastDocument Dokument mit der höchsten Nummer ermitteln und dann mit sowas wie
doc.getItemValue("AuftragsNr")(0)
den int oder long der Auftragsnummer erhalten.

4. Sich das Feld AuftragsNr als NotesItem-Objekt besorgen.
5. Dafür sorgen das das folgende tatsächlich als Zahl abgespeichert wird. Geht irgendwie mit NotesItem Klasse zuverlässig.  
6. Höchste Auftragsnr aus 3. mit 1 addieren und
7. fertig. Gespeichert wird ja nach querySave automatisch.


hoffe das hilft  8)


Titel: Re:lfd nr für dokumente in ner db
Beitrag von: Karotte am 07.05.03 - 10:47:05
@axel: dazu müsste der Nutzer erstmal wissen zuwas repliken da sind und wie sie eingesetzt werden ;)

bei mir soll es am ende auf folgendes herauslaufen: Das doc soll ne Nummer bekommen (vom System generiert), der Kunde kann dann in der Datenbank nachsehen was seine Aufträge machen: 3 Aufträge eingereicht: Auftrag 511 in Bearbeitung, Auftrag 544 noch nicht ausgelesen, Auftrag 509 abgeschlossen
Der Verkäufer sieht natürlich alles und soll Auftrag für Auftrag abarbeiten können. Das mit der kat. Ansicht hatte ich mir auch schon überlegt, da nummeriert ja LN auch von sich aus. Ich würd dann gern aber über die Nummer auf das Doc zugreifen können. Zum Bleistift 511 wurde zu 50% bearbeitet aber es fehlen zum bsp. noch 2 Teile, dann kann im Endeffekt der Verkäufer die Teile wenn sie da sind zu dem Auftrag zu buchen.

Naja ansonsten verwerf ich den ganzen schrott und grab die alte MX-300 mit HP-UX raus, da hatte ich mal ne Auftragsverwaltung
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: Axel am 07.05.03 - 10:58:51
Zitat
...dazu müsste der Nutzer erstmal wissen zuwas repliken da sind und wie sie eingesetzt werden

Hi,

unterschätz' die User nicht, denn sie wissen manchmal mehr als sie zugeben und was du meinst, dass sie wissen. Ausserdem sind viele Spielernaturen, so nach dem Motto: schau'n mer mal was da passiert...

Ein Lösungsansatz für dein Problem mit den Auftragsnummern wäre folgender, nimm eine Ansicht, die nach den Auftragsnummern  aufsteigend sortiert ist. Bei der Generierung eines Auftrags frägst du die Nummer des letzten Dokuments in dieser Ansicht ab und erhöhst diese um 1. Wenn noch kein Auftrag vorhanden ist, gibst du einfach eine Nummer vor, mit der dann begonnen wird. So was ähnliches hab ich in "grauer Vorzeit" mal gemacht.

Axel
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: jknoblich am 07.05.03 - 11:14:56
Ja an der laufenden Nummer scheiden sich die Geister :-)

Ich bin auch so langsam weg davon und nehme @unique .
Habe hier aber noch ne DB wo ich das mal so glöste hatte:
- ein Konfig-Doc, wo die letzte Nummer gespeichert wird
- eine Ansicht, wo nur das Konfig-Doc auftaucht

Wenn nun ein neues Doc erstellt wird, kann man nur über eine Schaltfläche speichern. Dabei hole ich mir aus dem Konfig-Doc die letzte Nummer und erhöhe sie um 1. Die Nummer wird dann in das aktuelle Doc eingefügt und dann auch noch im Konfig-Doc gespeichert.

Ist vielleicht nicht so schön, aber ich hatte das damals als Vorgabe:
"Wir wollen eine fortlaufende Nummer, die jedes Jahr neu beginnt..."
Titel: Re:lfd nr für dokumente in ner db
Beitrag von: ata am 07.05.03 - 15:43:30
... wir hatten hier im Forum eine Beipieldatenbank, die doliman damals im Forum gepostet hatte. Ich habe die DB bei mir schon ml in Verwendung. Mit kleinen Anpassungen läuft di ganz passabel..

ata