Domino 9 und frühere Versionen > ND6: Entwicklung

@ERROR bei Nummer aus Notes.ini

<< < (3/5) > >>

LUSBernd:
JA, er erfragt jedesmal eine Nummer.
Nein, er ist noch kein Roaming User; wird er aber bald werden. Er arbeitet aber von seinem LAptop aus und wählt sich bei Bedarf via VPN ins Firmennetz.
Wenn es schief läuft steht das @ERROR drin. Bis er die richtige Nummer einsetzt. NAch einigen Eingaben fliegt die Nummer dann wieder raus.

Das mit der fortlaufenden Nummerierung habe ich schon einmal kurz überflogen. LEider habe ich im Moment keine Zeit eine vernünftige Lösung dafür zu finden. Deswegen soll der jetzt erst einmal nur funzonieren. Sobald ich aber wieder ein wenig Luft habe werde ich mich darum kümmern.

Philipp

Thomas Schulte:
Tut mir leid aber irgendwie passen für mich hier die Aussagen nicht zusammen.

Entweder erfragt er sich jedesmal (bei jedem neuen Auftrag) eine Auftragsnummerbei der Buchhaltung, dann ist das mit der Environment Variable nicht notwendig.
Oder er hat diese Nummer im Environment, dann muss er nicht fragen.

Wenn er die Nummer im Environment hat, und du bekommst diese Fehlermeldung die du genannt hast, dann ist das zu irgendeinem Zeitpunkt X keine Nummer mehr.
Weil irgendein nicht numerisches Zeichen in deiner Variablen in der Notes.ini drinsteht.

Um rauszufinden was da vorgeht hast du zwei Möglichkeiten. Entweder baust du in deine Formel einen @prompt([OK];"Debug Bestellnummer ist %" + Temp + "%") mit ein, oder du hast (findest) eine Möglichkeit dich auf seinen Rechner draufzuschalten mit VNC oder einem anderen Remote tool und direkt in die Notes.ini die er verwendet reinzuschauen.

Alles andere ist pure Raterei.

koehlerbv:
Ich lese das so, dass Philipp bisher immer von dem Wert in der INI sprach. Und es kann ja durchaus sein, dass irgendeine andere DB genau den selben Variablennamen in der INI auch verwendet. Dann muss dieses krude "Verfahren" natürlich irgendwann knallen.
Philipp oder der betroffene Kollege müssen einfach mal VOR der Anlage eines neuen Angebotsdokuments prüfen, was in der INI-Variablen drinsteht. Vielleicht ergibt dieser Wert dann den entscheidenden Hinweis.

Was ich nicht so ganz verstehe: Mit dem angewandten "Verfahren" nummeriert ja jeder Bearbeiter immer nur seine eigenen Angebotsnummern. Und das liesse sich nun wahrlich geschickter anstellen (und ist nicht so komplex wie eine übergreifende fortlaufende Nummer).

Bernhard

LUSBernd:
also, inzwischen ist klar das nur bei dem Einen Müll in der ini steht. Allerdings scheint mir das dann doch ein globaleres PRoblem zu sein. Lustig ist nur dass es so lange gut ging!! Ist jetzt auch wurscht.

Ich denke ich muss einfach mal tief Luft holen und mir jetzt die Zeit nehmen den Käse in den Griff zu bekommen.

Es ist richtig, dass die alle irgendwann ihre eigenen Nummern haben. (und die dann irgendwann doppelt sind). Das ist aber nicht so schlimm. Damals war das auch so gewollt. Das Problem lag nämlich damals, als wir es noch gar nicht anders wussten, dass die Benutzer, die diese DB hauptsächlich nutzen in der Regel offline arbeiten. Und uns ist damals einfach keine bessere Lösung eingefallen. Das der immer dann in der Buchhaltung ne neue Nummer erfragt hat ist einfach nur Zufall. Da sitzt nämlich die Hauptansprechpartnerin von dem.  Die hat halt immer irgendeine Nummer genannt.



Die Frage, die ich  mir jetzt stelle ist: Gibt es überhaupt für Offline arbeitende Benutzer eine bessere Lösung???

Philipp

Thomas Schulte:

--- Zitat von: LUSBernd am 18.09.07 - 11:47:30 ---Die Frage, die ich  mir jetzt stelle ist: Gibt es überhaupt für Offline arbeitende Benutzer eine bessere Lösung???

--- Ende Zitat ---
Wenn du tatsächlich eine Zentrale Nummer meinst die für alle sauber hochgezählt wird dann ist die Antwort: Nein, es gibt keine Lösung die dir sofort eine fortlaufende Nummer gibt, ohne das du in irgendeiner Form mit einem Server Kontakt aufnehmen musst.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete