Beiträge von aweinrei

mit notes 8.5 könntest du auch daos benutzen um X mal 5 mb plattenplatzverschwendung zu vermeiden. allerdings ist deine aufgabenstellung an sich mal wieder ein organisatorisches problem "wie verteile ich einen anhang an X personen" -> ablagesystem ...

RockWilder: das würde ja das komplette dokument kopieren, nicht ausgewählte items innerhalb der dokumente.

Detti: über einen agent die ausgewählten dokumenten verarbeiten (db1.unprocesseddocuments). dann in der ziel db neue dokumente erstellen (db2.createdocument) und die entsprechenden items kopieren.

ich hatte ja folgendes vermutet (oder gehofft):
copytodatabase geht davon aus, das sich die links auf dokumente innerhalb der ziel-db beziehen. d. h. wenn ich doc1 und doc2 (mit link auf doc1) kopiere, funktioniert der link anschliessend wieder/immer noch.

daher könnte man ja vermuten, das wenn ich nur doc2 kopiere (der link ist dann erst mal kaputt) und dies wieder 'rückgängig' mache, der link danach in der ursprungsdb auf doc1 wieder funktioniert. leider hat sich das in meinen tests bisher so nicht dargestellt ...

hi taurec,

mit copytodatabase von der db1 in die db2 ist der link 'kaputtgegangen'. jetzt versuche ich erst mal mit copytodatabase von der db2 in die db1 das ganze zu 'reparieren' (wenn überhaupt so noch möglich (anscheinend nicht)).

danach würde ich dann mit einem copyallitems von db1 in db2 versuchen das ganze wieder herzustellen.

hab das mal gemacht.

war irgenwie ein agent der in der perweb lief (bin mir jetzt nicht sicher ob das an der stelle zwingend notwendig war). dort habe ich einfach alle dokumente einer db über eine zusammengebastelte url aufgerufen (http task muss auf server laufen). dann hatte ich alle dokumente als html in der perweb. alle details habe ich an der stelle leider nicht mehr im kopf ...

vielleicht hilft das aber schon mal als denkansatz.

auch wenn ich hiermit langsam zum alleinunterhalter werde:
wollte jetzt einen agenten erstellen, der mir die bereits kopierten dokumente 'repariert'.

erst copytodatabase zurück in alte db und dann einfach wieder die items in dem kopierten dokument austauschen. leider funktioniert der doclink im zurückkopierten dokument auch nicht mehr, was sich mir allerdings nicht ganz erschliesst.

schaut man sich die eigenschaften des links an, gibt es 3 werte.
- Replica
- View
- Note

Replica ist nach dem kopieren wieder auf dem richtigen wert.
View und Note allerdings nur die letzten 16 stellen (ab -ON).

evtl. hier jemand eine idee wie ich das wieder 'retten' kann (ohne rücksicherung ...)

oder evtl. über rollen. z. b.
@If(
@IsMember("[RolleA]";@UserRoles); "grün":"lila";
"grün":"blau":"rot")

kommt halt auf deine anforderung an / wieviel flexibilität verlangt wird

hier noch meine bisherige lösung (falls mal jemand ein ähnliches problem hat):

Set tmp_note = work_note.CopyToDatabase(archive)
Forall items In tmp_note.Items
If Ucase(items.Name) <> "$REF" Then
Call items.Remove()
End If
End Forall
Call work_note.CopyAllItems(tmp_note, False)
Call tmp_note.Save(True, False, True)

damit funktionieren die alten links noch und eine evtl. antwortstruktur bleibt bestehen.

ansonsten sollte copytodatabase wohl nur benutzt werden, wenn man
a) dokumente ohne links
b) eine komplette dokumentensammlung
kopiert ...

habe im notes.net einen ähnlichen 'fall' gefunden. evtl. gibt es einen unterschied zwischen
call doc1.copytodatabase(db2)
und
set doc2 = doc1.copytodatabase(db2)

kann das evtl. jemand bestätigen?

update:
so, habe langsam das gefühl, das es 'works as designed' ist.

technote 1092802 beschreibt das ganze. witzig ist halt nur, das der text, der in der statuszeile angezeigt wird, noch den alten datenbanknamen enthält und so doch etwas für verwirrung sorgt.

prüfe jetzt, ob ich meine routinen auf
set doc2 = db2.createdocument
call doc1.copyallitems(doc2)
umstellen kann

daher erst mal auf [erledigt] ...

sitze gerade an einem seltsamen problem.

aus datenbank a wird ein dokument (mit doclinks innerhalb der datenbank) über copytodatabase in eine zweite (b) dupliziert. dort funktionieren die doclinks aber nicht mehr.

erste analyse: die doclinks im neuen dokument zeigen plötzlich in die zweite (b) datenbank?

irgendeine idee? stehe ich auf dem schlauch?

werde noch versuchen das ganze in einen einfachen codeschnipsel zu verpacken um der sache näher auf den grund zu gehen ...

selectdocument setzt soviel ich weiss nur den haken in der ansicht. ein antwortdokument wird auf dem dokument erstellt, das mit der maus 'markiert' (also angeklickt) wurde.

evtl. hilft es dir, wenn du das dokument vorher öffnest und dann das antwortdokument erstellst.

99% aller unerklärlichen fehler lassen sich so lösen:
cache.ndk löschen
bookmark.nsf löschen (bzw. dokumente aus (ByURL) löschen)
kachel aus dem arbeitsbereich entfernen + arbeitsbereich komprimieren

so einen fall wie du hatte ich auch schon mal. da hatte das system 'behauptet' es gibt ein uidoc obwohl ich in der ansicht war ...

läuft auf dem server die http task? dann probier es doch einfach über pass-trough html in der maske (evtl. computed text).

wie sieht es mit es mit singlecategory als parameter aus? müsstest dann halt eine kategorsierte ansicht nehmen.

oh man, das war mal wieder ne schwere geburt ...

es lag daran, das sich unter den dokuementen noch antworten befanden und diese hatten andere leseberechtigungen als die hauptdokumente.

aufgefallen ist es erst, als ich ich mit ++ die ganze ansicht 'aufgeklappt' habe.

hi,

habe in einer ansicht 'leere kategorien nicht anzeigen' aktiviert. trotzdem werden leere kategorien weiter angezeigt. in der datenbank wird mit leser felder gearbeitet, was das ganze ja prinzipiell nicht beeinflussen sollte bzw. dafür ist es ja eigentlich gemacht.

server ist 7.0.3 auf aix, client ist 6.5.4

in meiner test-db funktioniert es interessanter weise. habe auch schon einen updall -V auf die produktiv db durchgeführt.

irgendwelche ideen oder hinweise wo diese funktion buggy sein könnte?

berechtigungen mit gruppen haben das ergebniss das immer die summe der maximalen rechte zieht.

du kannst nur die user dieser gruppe einzeln eintragen (und dann 'nicht berechtigen') oder du machst es wie warsn vorgeschlagen hat.

je nach anzahl der dokumente geht ja evtl. auch eine dialogliste:

_a := @DbColumn(vorhandene dokumente)
_b := @DbColumn(alle möglichen ip adressen)
_c := @Unique(_a : _b) '//damit sollten alle benutzten vorne stehen
_d := @Subset(_c; (@Elements(_b) - @Elementes(_a) * -1)) '//die übrig gebliebenen rausziehen

_d sollte dann alle freien enthalten.

klappt natürlich nur, wenn die bekannten notes grenzen dadurch nicht überschritten werden.

in einer mail-in db drückt ein anwender die 'löschen' schaltfläche bei einem geöffneten dokument. es wird dann wie gewohnt das nächste dokument angezeigt, schaut man dann in die ansicht / inbox ist das dokument allerdings nicht gelöscht und auch nicht zum löschen markiert. drückt man die 'löschen' schaltfläche in der ansicht / inbox wird das dokument in den papierkorb verschoben.

es kann also kein rechte problem sein.

cache-elemente wurden gelöscht -> kein erfolg.

das problem tritt wohl bei mehreren benutzern dieser db auf. versuche ich es an meinem client wird das dokument korrekt gelöscht.

habe soft-deletion zur sicherheit bereits einmal aus- und wieder eingeschaltet.

irgendwelche weiteren ideen?

bei uns läuft es problemlos auf ts 2003 (ok hilft dir jetzt nicht wirklich weiter). denke aber mal das es dort ähnlich problemlos funktionieren wird.

wenn du ein paar erfahrungen gemacht hast, wäre es sehr schön, wenn du diese dann auch hier postest. gibt mit sicherheit ein paar leute die das brennend interessiert.