R 4.5 Server und R.5 Client

[tabama]

Hallo,

habe einen R4.5 Server.
Die Clients sind alle schon auf R.5.
Nur meiner war bisher noch R.4.5.

Da ich aber einige Neuerungen des R.5 nutzen wollte, habe ich nun meinen AP auch auf R.5 umgestellt. Danach habe ich eine "neue" script-Methode "uiview.selectdocument(doc)" ausprobiert.

Beim speichern meckert der Designer nichts an.
Beim Ausführen der sub aber kommt es zu einem Fehler.

Danach habe ich eine neue Ansichteneigenschaft "leere Kategorien nicht anzeigen" ausprobiert. Auch hier kein Erfolg.

Brauche ich auch einen R.5 Server?

[Glombi]

Brauche ich auch einen R.5 Server?

Ja, denn sonst kannst Du die neuen R5 Features nicht nutzen.

Andreas

[koehlerbv]

UI classes werden auf dem Client ausgeführt und haben mit dem Server nix zu tun.

Es wäre auch ausgesprochen freundlich, wenn Du ein ganz klein wenig näher "den Fehler" erklären würdest.

Bernhard

[tabama]

Zu Problem 1 (Methode)

'doc ist als global vorhanden
dim ws as new notesuiworkspace
dim uiview as notesuiview
set uiview = ws.currentview
call uiview.selectdocument(doc)

schon das "set" funkt nicht, weil es eine R5 Eigenschaft ist. Folglich bringt die Methode "selectdocument" einen Fehler, weil das Objekt uiview nicht belegt ist.


Zu Problem 2 (Ansicht)
Ich habe eine kathegorisierte Ansicht in der Dokumente mit Leserfelder sind (nicht jeder sieht alle Dokumente). Es sind aber alle Kathegorien zu sehen (zunächst nicht so schlimm) aber eine Summenspalte wird ebenfalls für nicht belegten Kathegorien angezeigt.

[Semeaphoros]

Bernhard hat im Grundsatz schon recht, sofern der Server die notwendigen Informationen zu liefern vermag. Da die Konfig von Lotus nicht empfohlen wird, gibt es leider auch keine offizielle Liste, was denn nun so funktioniert und was nicht. Solange die DB auf dem Server liegt, gilt im Prinzip das, was Andreas gesagt hat.

[tabama]

Danke,
wenn es mir leider auch nicht weitergeholfen hat.

Gruß Martin

[koehlerbv]

Die Fragestellung von Martin (nachdem sie richtig klar wurde - nix für ungut, Martin   ) hat schon was.
Folgender Test (ich habe by the way übrigens noch nie mit NotesUIView.SelectDocument gearbeitet - ergab' sich einfach nicht):
Ich mach mir 'ne DB mit 'ner simplen Maske + simplen Vieh und baue dort 'nen Buhtong zum Markieren des zweiten Docs.
Zwei Docs eingegeben, dann den Buhtong gedrückt. Geht sich.

Nun DB ins ODS20 gebracht und gespannt auf's "Gnöbbel" gedrückt - geht sich auch. Dummerweise habe ich jetzt aber keinen R4-Server zur Verfügung (naja, doch, im Keller, aber den schliesse ich jetzt nicht wieder ans Netzwerk an ;-)

Was geht also eigentlich wirklich ab ? Eigentlich sollte sich doch der Client die erforderlichen Daten vom Server ziehen und damit zur Verfügung haben und DANN diese Daten lokal bearbeiten. Daten bekommt er entsprechend ODS20 ...

Wie gesagt: Ein interessantes Problem ...

Weiter grübelnd / recherchierend (wir haben ja bald den Designer 7, stimmt, Semeaphoros ?

Bernhard  

[Glombi]

Danke,
wenn es mir leider auch nicht weitergeholfen hat.

Gruß Martin

Wieso nicht? Du musst halt einen R5 Server aufsetzen. Das solltest Du sowieso dringend machen, wenn bereits alle Clients auf R5 sind !

Andreas

[Semeaphoros]

Nö, das geht sicher nicht so ab, wäre ein schlechtes C/S [well Client/Server, nicht Cal&Sched] Design. Die ODS spielt hier ziemlich sicher keine Rolle (die hat nur in sehr, sehr wenigen Fällen Einfluss auf die Funktionalität). Das Grundprinzip eines sauberen C/S Designs ist aber, dass der Server so viel Arbeit wie möglich selber macht und nur Resulate zurückliefert und damit natürlich (normalerweise) Banbreite des Netzes und Resourcen des Clients schont. Bedeutet kurz gesagt: wenn immer möglich werden die Funktionen via RPC (Remote Procedure Call) auf dem Server ausgeführt und nicht lokal. Genau das geht hier auch ab, Notes/Domino arbeit sehr intensiv mit dieser Technologie, soweit sich das von den Kommentaren der Entwickler her beurteilen lässt.

[koehlerbv]

@Andreas:
Genau so ist es. Und was empfiehlt IBM: Erst die Server (!), dann die Klienten umstellen.

@Semeaphoros, @Martin:
So ganz traue ich bei FrontEnd-Klassen nicht auf eine hundertprozentige RFC-Funktionalität. Kann es vielleicht sein, dass Martin eine ODS41-DB auf den Server geworfen hat ? Da könnte ja auch was schief gehen ...

Bernhard

[Semeaphoros]

Na, ob das immer und überall sauber ist mit dem RFC sei dahingestellt, jedenfalls scheint es doch recht gut implementiert zu sein. Manchmal gibt es auch Gründe dafür, es anders zu machen.

Falsche ODS auf dem Server kann nicht sein, da würde der Server eine Fehlermeldung ausspucken vonwegen unbekanntem File-Format oder so

[koehlerbv]

Klar, ODS41 auf R4 geht ja nicht. Sorry für diesen Dummspruch meinerseits.
Vielleicht sollte man mal Martin meine DB ausprobieren lassen ? Es kann ja auch sonstwas nicht stimmen ...

Bernhard

[Semeaphoros]

Glaube nicht, dass das ein anderes Resultat ergibt, wie gesagt, die ODS spielt hier ziemlich sicher keine Rolle sondern die im Servercode vorhandene Funktionalität. Wenn Du ODS 20 auf einem R5er Server hast, hast Du Performance-Einschränkungen, aber so gut wie keine eingeschränkte Funktionaltiät.