Domino 9 und frühere Versionen > ND8: Administration & Userprobleme

Agent prüft keine Doppeleinträge mehr

<< < (7/8) > >>

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  ;D
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 ...

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete