Agent prüft keine Doppeleinträge mehr

[koehlerbv]

So, wie das in der Ansicht steht, kannst Du nahezu einen darauf lassen, dass die Werte so wie in der Spalte auch im Dokument selbst drin stehen, Mike.

Du musst also alle Stellen suchen, in denen bei den Zeiteinträgen das Datum gespeichert werden könnte. Dabei wirst Du auch entdecken, ob da in Bezug auf das Format irgend ein Settings-Dokument herangezogen wird.

Aber egal wie: Die ganze Anwendung scheint doch ein wilder Verhau zu sein und als Nicht-Profi stehst Du auf eigentlich völlig verlorenen Posten.
Diese Stelle ist schon schräg: Die View verwendet ein Format (siehe Dein Codeauszug)

we need to convert into the format mm/dd/yyyy because it is used in the view

Ins Dokument kann aber offensichtlich auch etwas anderes geschrieben werden.
Da scheint also nicht mal durchgängig der Datentyp Date/Time verwendet zu werden.

Bernhard

[tron55]

Oh mann da bekommt man ja Pickel.


Aber aufgeben ist keine Option ...  


Sieht auch ok aus, ich kapier es nicht.

TimeReportDate
Vorgabewert

@If( TimeReportDateDefault =""; @Today; TimeReportDateDefault)

Und der zweite Screenshot zeigt die Infoboxsettings

[koehlerbv]

Aber was ist im Dokument gespeichert (nicht aus geöffnetem Dokument abfragen! Und wie ist die Ansichtsspalte definiert?
Wozu dient das Item TimeReportDateDefault und wie ist das definiert?

Wenn im Dokument immer Date/Time steht, in der Ansicht aber was alternierendes im Format, dann besteht da eine offensichtliche programmatische Diskrepanz.

Bernhard

[tron55]

-In den verschidenen Sichten wird das Datum immernoch als tt.mm.yyyy dargestellt.

-Das ist davon abhängig welche Ansicht ich frage -das ist leider nicht konsequent übernommen in jeder Ansicht.
Ich liste mal ein paar auf:

1) Standardansicht # Time Reports \ day # Programmiername: TimeReportDate #Stil: Allgemein # Beispiel: ---
(klingt schon mal nicht verkehrt...)

2) Ansicht UserTimeReports # Programmiername : $19 # Stil:  Datum/Zeit Beispiel: 09/19/2011 18:39:45

3)[Time Reports \ month # Programmiername: TimeReportDate #Stil: Allgemein#Beispiel: ---

usw...

Auf welche Sicht der sich vor dem formatieren konkret bezieht konnte ich halt noch nirgends rauslesen.

- TimeReportDateDefault ist ein Feld in der Maske das scheinbar das Defaulformat dort festlegt (screenshot)
Normalerweise würde ich vermuten dass das Ding nix mit dem problem zu tun hat weil es webclients bedienen will, auf der anderen  Seite hab ich den
Eindruck das "webquerysave" eh alles erledigt.

[koehlerbv]

Mike, Du hast keine meiner (wirklich) Fragen beantwortet ...

Bernhard

[tron55]

Ich probiers nochmal, aber die Formulierungen sind etwas weit gefasst.

Aber was ist im Dokument gespeichert

Im Dokument wird das  Datum in der Form mm/tt/yyyy gespeichert.
In der StandardAnsicht hingegen ist es dd.mm.yyyy.
Hoffe das hast du gemeint.

Und wie ist die Ansichtsspalte definiert?

Verstehe nicht so genau was du hier wissen willst, wenn nicht das Zeitformat und das ist wie schon beschrieben auf STIL:Allgemein eingestellt und
hat damit kein Anzeigeformat im Datumformat.

Wozu dient das Item TimeReportDateDefault und wie ist das definiert?

Kann ich nicht genau sagen, aber es taucht in der Formel auf die hinter dem Feld TimeReportDate liegt und zwar in dieser Form.

@If( TimeReportDateDefault =""; @Today; TimeReportDateDefault)

und schlussendlich stellt man über TimeRepotDate ja das Datum ein.

Wenn wir uns wieder nicht verstanden haben  sach ich schonmal "sorry ich habs probiert"! 

[koehlerbv]

Was steht in den Dokumenteigenschaften bei Datentyp? Nochmal: Öffne das Dokument nicht - schau Dir das aus der Ansicht heraus an.

Weiters: Wie ist die Datumsspalte formelmässig festgelegt? Da muss ja was stehen 

Nochmals: Du kannst in der Ansicht durch Einstellungen des OS oder vom Domino was verbiegen, aber niemals so, dass da mal mm/dd/yyyy steht und mal dd.mm.yyyy. Zumindest nicht, wenn mit purem Notes Dates/Time gehandelt wird. Entweder oder ... Es muss an den Dokumenten selbst liegen.

Bernhard

[tron55]

Was steht in den Dokumenteigenschaften bei Datentyp? Nochmal: Öffne das Dokument nicht - schau Dir das aus der Ansicht heraus an.

ok nun hab ich's verstanden.

Ich hab mir einfach ein Dokument in der Standardansicht genommen, "rechtklick" + "Dokumenteneigenschaften" und heraus kam das was in screenshot 1+2+3 zu sehen ist .

Die Maske ist ok.
Der Datentyp TimeReportDate liefert ein "falsches" Datum , nämlich in dem Format das wohl für den Fehler verantwortlich ist. (dd.mm.yyyy)

Weiters: Wie ist die Datumsspalte formelmässig festgelegt? Da muss ja was stehen  

Die Datumsspalte kann ich mir ja im Client nicht anschauen, sondern dazu gehe ich in den Designer, wieder in die Standardansicht "Time Reports \ day"
(mir ist noch unklar ob es egal ist welche Ansicht ich nehme oder ob das eine bestimmte sein muss)
Wenn ich dort in der entsprechenden Ansicht die Spalte "Date" anwähle. kann ich mir den Programmiernamen im letzten Reiter rauslesen: "TimeReportDate"

Den Kollegen kennen wir ja mittlerweile, also suche ich ihn in der Maske "TimeReport"

Das Ergebnis kannst du in Screenshot 4+5 sehen.

Gruß
Mike

Beim aufschreiben kam mir ein Gedanke..
Steht in dem Skript nicht sinngemäß " ich wandle dd.mm.yyyy zu mm/dd/yyyy um"
Wenn ich mir den Screenshot anschaue ist die Spalte aber schon mit mm/dd/yyyy definiert.
Wird deshalb vielleicht die Funktion die prüft erst gar nicht ausgeführt?

[tron55]

Screenshot 4+5

[koehlerbv]

ok nun hab ich's verstanden.

Nö.

Ich hab mir einfach ein Dokument in der Standardansicht genommen, "rechtklick" + "Dokumenteneigenschaften" und heraus kam das was in screenshot 1+2+3 zu sehen ist .

Die Maske ist ok.
Der Datentyp TimeReportDate liefert ein "falsches" Datum , nämlich in dem Format das wohl für den Fehler verantwortlich ist. (dd.mm.yyyy)

Gewählte Ansicht ist okay, da die Maske (Form = ...) passt. Und Dein nächster Schluss ist falsch - TimeReportDate ist sauber als NotesDate/Time abgelegt! (Daraus kann man sich für Laufzeit und Ansicht was anderes basteln, aber es anders zu speichern, ist tödlich!)

Die Datumsspalte kann ich mir ja im Client nicht anschauen, sondern dazu gehe ich in den Designer, wieder in die Standardansicht "Time Reports \ day"

Falsch. Du hättest die Suchansicht des Agents nehmen sollen und dort zwei Dokumente anschauen, die eben unterschiedliche Datumsformate anzeigen. Sind die Dokumente dann im betreffenden Item wieder mit NotesDate/Time gefüllt? Und was steht in der Suchansicht in der betreffenden Spalte als Formel?

Beim aufschreiben kam mir ein Gedanke..
Steht in dem Skript nicht sinngemäß " ich wandle dd.mm.yyyy zu mm/dd/yyyy um"
Wenn ich mir den Screenshot anschaue ist die Spalte aber schon mit mm/dd/yyyy definiert.
Wird deshalb vielleicht die Funktion die prüft erst gar nicht ausgeführt?

Das ist komplett verkehrt und hat mit der Programmierung nichts zu tun.
Glaubst Du nicht, Du lehnst Dich mit dem Versuch, das ganze zu verstehen und im Produktivbetrieb eine Änderung herbeizuführen, ziemlich weit aus dem Fenster? Ich achte Dein Engagement wirklich, aber Du kannst mit Deinem derzeitigen Wissensstand m.E. eher etwas kaputt machen als nachhaltig (!) reparieren.

Bernhard

[tron55]

Achso falsch verstanden.
Dummerweise ist die Formel leer bzw ein "/" steht als Suchbegriff dort wenn ich den Agent in die Suche lade.

In der Ansicht UserTimeReports wird Dokument a dann dd.mm.yyyy dargestellt und dokument b mm/dd/yyyy
In beiden Items steht aber die NotesDate/Time im Item also mm/dd/yyyy.

@Rest
Das kann alles nicht so wild sein, weil dort niemand was mit Absicht geändert haben kann.
Wir sehen es halt einfach nur nicht momentan und sowas macht mich noch viel fuchsiger 
Außerdem habe ich natürlich Backups.

[Tode]

Sorry, ich lese hier schon ne Weile mit, und Bernhard hat wirklich ne ENGELSGEDULD... Ich wäre schon lange oben raus gegangen...

Könntest Du wenigstens mal VERSUCHEN, das zu machen, was er Dir sagt? Du vermutest und dokterst und versuchst die (vermeintlichen) Auswirkungen zu beheben, ohne die Ursache zu verstehen.

Ich fasse mal zusammen:

1. Die Ansicht, die der Agent verwendet ist scheinbar vollkommen OK, es sind die Daten, die Mist sind...
2. Scheinbar wurden früher Dokumente korrekt erstellt (Dein Screenshot: Das Feld ist DateTime, das passt so), aber nun werden -und da bin ich ziemlich sicher- Dokumente von irgend einem Client oder einer Funktion falsch erstellt. In den Eigenschaften dieser Dokumente wirst Du mit grosser Wahrscheinlichkeit sehen, dass da in den Feldeigenschaften als Datentyp "Text" steht...

Jetzt kannst Du versuchen, die Auswirkungen mit Hilfe einer Formel in der Ansicht zu korrigieren, ich sage "versuchen", weil Du da sicherlich nicht alle möglichen Auswirkungen berücksichtigt bekommst, und vermutlich nur 95% der Dokumente (oder weniger) erfasst (auch wenn es bei Deiner aktuellen Datenlage OK aussieht).

Oder Du behebst die Ursache... Und dazu brauchst Du
a) Die Möglichkeit analytisch an ein Problem ranzugehen
b) Die Fähigkeit, Anleitungen zu VERSTEHEN und vor allem zu BEFOLGEN
c) Verständnis des Codes, der das ganze produziert...

Ich erlaube mir jetzt kein Urteil, ob Du a, b, oder c besitzt, das musst Du selbst einschätzen....
Ich jedenfalls würde Dir empfehlen, jemanden zu Hilfe zu rufen...

[Peter Klett]

Hallo Tode,

Du irrst mit Deiner Annahme, dass die neuen (oder die alten) Dokumente falsch sind. Ich hätte auch darauf gewettet.

tron55 hat tatsächlich Deinen letzten Rat befolgt und jemanden um Hilfe gebeten. Ich habe mir also eine Kopie der Datenbank mit zwei Testdokumenten angesehen. Normalerweise würde ich nicht darüber schreiben, aber ich war auch recht verblüfft über das Ergebnis, so dass ich denke, dass ich mit meinen paar Zeilen keinen groben Fehler begehe.

Die Formel in der Datumsspalte lautete

@Text (Datumsfeld) (den Feldnamen habe ich schon wieder vergessen)

Warum die alten Dokumente in der Ansicht amerikanisch und die neuen deutsch ausgegeben wurden, kann ich nicht sagen. Vielleicht hatte die Ansicht einen Schlag weg. Ich vermute, dass zwischen den alten und den neuen Dokumenten eine Einstellung am Server geändert wurde, so dass die Umwandlung des Datums in Text vorher amerikanisch erfolgte, und später deutsch. Angeblich war die Ansicht heute früh einheitlich im Format, dann allerdings deutsch.

Vielleicht irre ich mich (dann bitte korrigieren), aber ich meine, dass Spalten, in denen mit DBLookup oder GetDocumentByKey gesucht wird, Text beinhalten müssen, weil es sonst nicht funktioniert. Daher ist es schon korrekt, das Datumsfeld in der Spalte in Text umzuwandeln.

Die Änderung bestand nun darin, nicht einfach @Text (Datumsfeld) zu nutzen, sondern das Datum hart in einen Text umzuwandeln, ohne dass Serversettings da reinspielen können. Gleiches gilt auch für die Suchroutine. Nun wird sowohl in der Spalte als auch in der Suchroutine der korrekt im Datumsformat abgelegte Feldinhalt immer in amerikanisches Format (mm/dd/yyyy) umgewandelt, unabhängig von Client- oder Servereinstellungen. Und schon funktioniert es.

[Tode]

Also: @Text( Datumsfeld ) ist natürlich ein Mega- Fehler... Da weiss ich ja nie, was am Ende rauskommt. Dass die Ansicht halb halb war... Nun das würde ich auf einen defekten Ansichts- Index schieben...

Aber es ist ja schön, dass mit Deiner Modification das alles wieder einheitlich ist...

Wenn ich sowas mache, drehe ich im übrigen die Anzeige immer so ist:
20110920

1. Saubere Sortierung
2. Unabhängig von . oder / als Trenner...

Aber ist natürlich Geschmackssache...
Da bin ich

[Peter Klett]

Hallo Tode,

da gebe ich Dir absolut recht, ich verwende sonst für solche Anlässe auch das textlich sortierbare Datumsformat ohne Trennzeichen. Das sehe ich auch noch nicht einmal als Geschmacksache, sondern als das sinnvollste Format, vollständig, sortierbar und minimale Datenmenge.

Hier ging es darum, möglichst den Urzustand wiederherzustellen, und der war amerikanisches Format. Vermutlich niemand weiß, wozu die Ansicht sonst noch benötigt wird, und eh man da eine Riesenbaustelle aufmacht ...

[tron55]

Hallo,
 
bin leider gerade erst nach Hause gekommen, daher poste ich erst jetzt.
Peter hat ja eigentlich alles beschrieben und mir sehr geholfen genau wie Bernhard auch, dafür vielen Dank.

Peter hat auf jeden Fall Recht; ich hatte auch vermutet das jemand das Serverformat auf deutsch geändert hat
(weshalb auch immer!) .

Die angesprochene verkorkste Formel im Datumsfeld + die kaputte Ansicht + die Änderung des amerikanischen Formats des Servers haben jeweils ihren Teil dazu getan das ich da jedenfalls nichts analytisch herleiten konnte.

Jetzt geht es auf jeden Fall.
Vielen Dank.

@Tode
Keine Ursache