Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: GSYS am 12.01.06 - 13:41:04
-
Ich habe folgendes Problem im Rahmen einer Projektarbeit für eine Fahrzeugverwaltungsanwendung habe ich eine Maske für die Fahrzeugeingabe entworfen. Dazu habe ich dann auch die passende Ansicht erstellt. Wenn ich die Datenbank in Notes starte komm ich automatisch auf die Ansicht, so soll es auch sein. Wenn ich dann auf einen Datensatz klicke komm ich automatisch in die Maske, auch ok. Aber hier sollen die Felder dann nicht mehr bearbeitbar sein. Wie bekomm ich das hin? Ich habe die Eingabemaske kopiert d.h. ich habe eine Maske für den Admin. der Fahrzeuge erfasst und die kopierte Maske als Fahrzeugdetails die soll dann nicht mehr bearbeitbar sein. Bitte Bitte helft mir so schnell wie möglich!
MFG Rene
-
Hierfür brauchst Du keine zwei Masken, sondern nur eine. Diese Maske muss dann ein Autorenfeld enthalten, in dem die Admin-Rolle steht. Siehe hierzu die DesignerHelp wegen Autorenfeldern.
HTH,
Bernhard
-
Danke Schön für den Tipp bin Neuling auf dem Gebiet :)
-
Ich habe was vergessen da ich nicht nur Textfelder habe sondern auch Zahl- und Datumsfelder kann ich nicht generell Autorenfeld wählen gibt es eine Möglichkeit die gesamte Maske for unberechtigten Feldwerteingaben zu schützen?
Danke im Voraus MfG Rene
-
Das Autorenfeld gilt für die gesamte Maske, egal viele Felder enthalten sind.
Axel
-
Aber es sind nur einige Felder als Autorenfeld definiert die anderen nicht.
-
Du brauchst nur ein einziges Autorenfeld. Bitte lese die Doku hierzu aufmerksam.
-
Ich hab es glaube ich ich habe bei den Maskeneinstellungen/Sicherheit
Alle Leser und höhere deaktiviert damit ist das problem beseitigt.
Was meinen Sie dazu?
-
Das ist falsch. Dokumente, die mit dieser Maske erstellt wurden, können dann nur noch die Personen / Gruppen / Server sehen, die dort ausgewählt wurden.
-
Ok ich mach es rückgängig wobei mir das, wenn nur ein Feld auf Autor gesetzt ist, dass die gesamte Maske vor unberechtigten Zugriff geschützt ist, sehr suspekt ist. ??? Schrecklicher Satzbau...
-
Warum ist dir das sehr suspekt?
Axel
-
Weil es schwer vorstellbar ist wenn ein Feld auf Autor gestellt ist das alle anderen Felder automatisch die Eigenschaft übernehmen.
-
Bitte lese die Doku ! Dir fehlen hier grundlegene Verständniszusammenhänge.
-
Aber so arbeitet Notes nun einmal.
Am Besten du liest dir das hier einmal durch:
Handling von Leser und Autorenfeldern, wann ziehen sie, wann nicht
Die 10 Regeln die Leser und Autoren Felder betreffen
Regel #1 - Die ACL hat immer das letzte Wort
Die Zugriffskontroll Liste (Access Control List (ACL)) bestimmt immer welche Art eines Zugriffes jemand auf eine Datenbank hat. Alle folgenden Regeln greifen
zu guter Letzt auf diese Regel zurück. Wenn jemand in einer Datenbank nur "Einlieferer" Rechte hat, dann kann er keine Dokumente lesen, egal was sonst noch
eingestellt wird. Diesen Benutzer in ein Leser oder Autoren Feld einzutragen wird keine Auswirkungen haben.
Regel #2 - Autoren Felder können keine Rechte verleihen die vorher nicht existierten
Ein Autoren Feld kann den Zugang zu einem Dokument nicht einschränken. Wenn ein Benutzer Editorenrechte (oder höhere Rechte) in der Datenbank hat, dann hat
ein Autoren Feld keine Auswirkungen für diesen Benutzer, was wieder auf Regel #1 zurückzuführen ist. Genau das gleiche gilt, wenn ein Benutzer nur Leser oder
ein noch niedrigeres Zugriffsrecht hat. Dann hat ein Autoren Feld wieder keinen Einfluß, weil die ACL sagt, das das einzige was dieser Benutzer tun kann
lesen ist. Als ganzes bedeutet das, das ein Autoren Feld nur dann anwendbar ist, wenn der fragliche Benutzer Autoren Rechte in der Datenbank hat.
Regel #3 - Leser Felder begrenzen den Zugriff
Ein Leser Feld begrenzt den Zugang immer und es hängt überhaupt nicht von den Zugriffsrechten des Benutzers ab. Wenn man ein Leser Feld in ein Dokument
einbaut und es mit einem Wert gefüllt ist, z.B. nur mit Ihrem Namen, dann haben sie und nur sie die Möglichkeit dieses Dokument zu sehen, vollkommen egal
welche Rechte der andere hat.
Regel #4 - Leser und Autoren Felder müssen immer den vollständigen qualifizierten Benutzernamen enthalten
Wenn sie Benutzer Namen in Leser oder Autoren Felder eintragen, müssen diese immer den qualifizierten Namen enthalten. Das bedeutet, das das "CN=" und alle
anderen Bestandteile wie UO ... im Benutzer Namen sichtbar sein müssen. Wenn das nicht der Fall ist, dann wird der Name nicht zu dem entsprechenden Benutzer
passen und der Benutzer wird keinen Zugang erhalten.
Regel #5 - Rollen können in Leser und Autoren Feldern benutzt werden
Um eine Rolle in diesen beiden Feldtypen verwenden zu können, muß der Name der Rolle in eckige Klammern gesetzt werden. So kann man zum Beispiel indem man
"[administrator]" in ein Leser Feld einträgt verhindern, das irgendwer der nicht diese in der ACL eingetragene Rolle hat dieses Dokument lesen kann.
Regel #6 - Wenn ein Leser Feld leer ist, dann kann jeder das Dokument lesen
Nur weil ein Leser Feld in einem Dokument existiert, heißt das noch lange nicht, das jedes einzelne Dokument das diese Maske benutzt Lese Sicherheit
eingebaut hat. Da Leser Felder den Zugang begrenzen, bedeutet ein leerer Wert, das der "Zugriff für niemand verboten" ist. Oder anders ausgedrückt. "jeder
darf zugreifen".
Regel #7 - Wenn ein Autoren Feld leer ist, dann kann niemand mit Autoren Rechten in der Datenbank dieses Dokument bearbeiten.
Da Autoren Felder den Zugriff auf ein Dokument garantieren, bedeutet ein leerer Wert, "hier bekommt keiner Zugriff" oder "niemand der Autoren Rechte hat darf
hier ändern". Benutzer mit Editoren oder höheren Rechten sind dann aber immer noch in der Lage diese Dokumente zu bearbeiten. Siehe Regel #1.
Regel #8 - Wenn es mehrere Sicherheits Felder (entweder Leser oder Autor) in einem Dokument gibt, dann wird im Hintergrund aus allen Werten in allen
Feldern ein "virtuelles" Sicherheits Feld gebildet, das für die Zugriffskontrolle genutzt wird.
Das muß man jetzt etwas ausführlicher erklären. Wenn man z.B. zwei Leser Felder in seiner Maske hat, von denen eines den Wert "[Administrator]" und das
andere den Wert "CN=Amadeus Tester/O=Testfirma" hat, dann ergeben diese beiden Felder zusammen, das alle die für diese Datenbank die Rolle "[Administrator]"
haben und außerdem der Benutzer Amadeus Tester dieses Dokument in einer Ansicht sehen können.
Um dieses Beispiel weiterzuentwickeln fügen wir man jetzt ein weiteres Leser Feld in das Dokument ein, lassen dieses Feld aber leer. Normalerweise bedeutet
ein leeres Leser Feld, das jeder das Dokument lesen kann, nur das in diesem Fall noch andere Leser Felder in dem Dokument sind, so das nicht ausschließlich
dieses neue Feld zur Kontrolle benutzt wird. Was jetzt passiert ist, das alle drei Leser Felder kombiniert werden um den Zugriff auf dieses Dokument zu
regeln. Wenn alle drei Felder ein "NULL" Wert (kein Eintrag) ergeben, dann kann jeder das Dokument lesen. Da die anderen beiden Felder aber nicht leer sind,
ändert das hinzufügen des dritten Feldes ohne Eintrag nichts an den Zugriffsrechten. Das Dokument kann immer noch nur von unserem Benutzer Amadeus Tester,
bzw. von allen denen die Rolle "[Administrator]" in der Datenbank zugewiesen wurde gelesen werden.
Bei Autoren Felder ist es der gleiche Vorgang. Mehrere Autoren Felder verbinden sich zu einem übergeordneten "virtuellen" Autoren Feld. Wenn jemand (mit
Autoren Rechten in der ACL, um noch einmal kurz auf Regel #1 hinzuweisen) in mindestens einem dieser Felder eingetragen ist, dann ist er in der Lage dieses
Dokument zu verändern. Es spielt auch hier keine Rolle ob ein Autoren Feld leer ist, während die anderen gefüllt sind.
Regel #9 - Wenn es sowohl Leser als auch Autoren Felder in einem Dokument gibt, dann sind die Autoren Felder auch Leser Felder
Diese Regel scheint auf den ersten Blick keinen Sinn zu machen. Also brauchen wir ein Beispiel. Nehmen wir an, daß dieses Dokument ein Leser Feld hat in das
die "[Administrator]" Rolle eingetragen ist. Außerdem hat das Dokument ein Autoren Feld mit "CN=Amadeus Tester/O=Testfirma". Weil Amadeus Tester im Autoren
Feld eingetragen ist, wird er automatisch auch in der Lage sein das Dokument in den entsprechenden Ansichten zu sehen. Er muß also nicht zusätzlich noch im
Leserfeld eingetragen werden. Das geht auf Regel #2 zurück. Das Leser Feld hat den Zugriff gelöscht, Das Autoren Feld ihn aber wieder garantiert.
Was ich zeigen will ist ,das hier Autoren Felder einen Unterschied für Benutzer machen können, deren Zugriffsrechte mindestens Editor oder höher sind. Wenn
Amadeus Tester der Entwickler dieser Datenbank ist, dann kommt das Autoren Feld ins Spiel und erlaubt es ihm die Dokumente in Ansichten zu sehen, obwohl er
eigentlich kein Leser ist.
Regel #10 - Leser Felder werden während der Replikation angewandt
Diese Funktionalität wird häufig übersehen. Dabei ist sie wirklich wichtig. Nehmen wir einmal an wir haben eine Datenbank mit zehn Dokumenten. Sie sind nur
in zwei dieser Dokumente eingetragen. Sie können nur diese zwei Datenbanken sehen aber wenn sie in die Eigenschaften der Datenbank gehen, dann sehen sie das
es zehn Dokumente gibt. Sie können auf dem Server keine Ansicht erstellen, aber sie wollen alle Dokumente sehen. Also erstellen sie eine lokalen Replik der
Datenbank, bauen dort die Ansicht ein die alle Dokumente zeigen soll und öffnen die Ansicht. Sie können aber immer noch nur diese beiden Dokumente sehen. Das
passiert nicht, weil die Leser Felder auf ihre Lokale Replik angewendet werden. Sie sehen tatsächlich alles. Wenn sie auf die Datenbank Eigenschaften der
Lokalen Replik gehen werden sie feststellen, das sie tatsächlich nur zwei Dokumente in dieser Datenbank haben. Domino/Notes läßt es nicht zu, das sie
Dokumente zu denen sie keinen Zugriff haben lokal replizieren.
In einer ähnlichen Art, kann man z.B. eine manuelle Replikation zwischen zwei Servern starten. Wenn es Dokumente gibt die sich geändert haben, oder Sie sehen
die Änderungen nicht, dann wurden diese Änderungen zwischen den beiden Servern nicht repliziert. Eine Sache die viele Entwickler vergessen, ist, das in eine
Datenbank immer eine Rolle mit eingebaut werden sollte die in ein Leser Feld eingetragen wird um "LocalDomainServers" das Recht zu geben Dokumente zu
replizieren.
Verschiedene Beobachtungen und Tipps
1. Geben Sie sich selbst Zugriff
Wenn Sie eine Anwendung entwickeln bei der sie Leser und/oder Autoren Felder benutzen werden, dann gibt es einige Dinge die sie beachten sollten.
Jedes einzelne Dokument, das ein Leser Feld hat das nicht leer ist, sollte automatisch auch ein zusätzliches Leserfeld enthalten in dem eine definierte Rolle
z.B. "[Administrator]" eingetragen wird. Wenn alle vorhandenen Leser Felder leer sind, dann kann jeder das Dokument sehen. Aber wenn eines der Leserfelder
gefüllt ist, dann können nur noch die Benutzer, die in diesen Feldern eingetragen wurden diese Dokumente sehen. Es ist schon häufiger passiert das ein
Entwickler nachträglich an einem Dokument in einer Datenbank arbeiten wollte weil lein Benutzer irgendwelche Fragen oder Probleme hatte. Er konnte das aber
nicht, weil er keinen Zugriff auf die entsprechenden Dokumente hatte. Deswegen konnte er nichts tun um Unterstützung für dieses Dokument zu leisten. Oder es
gibt in einer Datenbank ein Leserfeld in dem exakt ein Benutzer eingetragen ist und dieser Benutzer verläßt das Unternehmen. Das sind schwerwiegende Gründe
warum man immer ein "Administrator" Leser Feld mit einer entsprechenden Rolle mit einbauen sollte.
Normalerweise macht man das auf die folgende Art und Weise:
Man erstellt ein verstecktes "AdminReaders" Feld ganz am Ende der Maske. Das Feld ist vom Typ Leser und Berechnet. In der Berechnung des Feldes wird geprüft,
ob die Zusammenfassung aller anderen Leser Felder einen Wert enthält oder nicht. Wenn ein Wert eingetragen ist, dann wird die Rolle eingetragen. Zum
Beispiel:
@If(@Elements(Readers1 : Readers2 : Readers3) != 0; "[Admin]"; "")
Sie werden sich fragen, was für den Fall passieren soll, das die Anwendung "wirklich" vertraulich ist, und wenn die Eigentümer der Anwendung noch nicht
einmal den Support in die Dokumente schauen lassen wollen. In diesem Fall wird das AdminReaders Feld immer noch eingebaut. Nur die zum Zugriff benötigte
Rolle wird nicht in der ACL eingetragen. Auf diese Weise sieht der Entwickler der die Anwendung pflegt die Dokumente nicht. In der Bedienungs Anleitung der
Datenbank wird die Rolle aber genannt. Auf diese Art kann der Entwickler wenn er Zugriff benötigt (und glauben sie mir das ist keine Frage des ob sondern des
wann) zum Datenbank Verantwortlichen gehen und ihm sagen, das er diese Rolle in die Datenbank eintragen und ihm den entsprechenden Zugriff geben soll. Nach
Beendigung der Pflegearbeiten kann dem Entwickler die Rolle wieder entzogen werden. Wichtig ist, das diese "Hintertür" aber immer da ist wenn sie denn einmal
gebraucht wird.
Wenn man für die Öffentliche Hand oder eine Firma arbeitet, dann kann der obige Absatz einen dazu bringen sich wie ein Wurm zu krümmen, weil man
"Hintertürchen" in einer Anwendung nicht sehen will. Aber wenn der Entwickler der die Anwendung unterstützt keine Manager Rechte auf der Datenbank hat, dann
muß er erst zu dem jeweils Verantwortlichen gehen um diesen Zugriff zu erhalten.
2. Server Zugriff gestatten
Wenn die Datenbank zwischen unterschiedlichen Servern repliziert werden soll, dann sollte ein anderes zusätzliches Leser Feld eingebaut werden das eine
"[Replikator]" Rolle enthält (wenn notwendig). Hier muß man sicherstellen, das "LocalDomainServers" diese Rolle haben. Dieser Eintrag erlaubt es den Servern
alle Dokumente zu sehen und zu replizieren.
3. Leser Felder und Ansichten
Diese Eigenschaft von Leser Feldern wird von Entwicklern häufig übersehen und sie kann die Datenbank erheblich verlangsamen. Um das Problem zu verstehen
braucht man ein wenig Hintergrundwissen über die Art wie der Notes Client mit dem Domino Server zusammenarbeitet. Was jetzt kommt ist ein extrem
vereinfachtes Beispiel:
Wenn eine Ansicht geöffnet wird dann sagt der Client zum Server, Ok Junge gibt doch bitte mal den ersten Teil des Ansichts Indexes. Der ganze Index kann
ziemlich groß sein, so das zunächst einmal nur ein Brocken des Indexes gesendet wird um die Geschwindigkeit zu erhöhen. Das kann man sehen und nachvollziehen
wenn man eine große Ansicht öffnet, das oberste Dokument markiert und dann mit der Pfeil-unten Taste nach unten scrollt. Irgendwann wird es eine Pause geben.
Das ist der Zeitpunkt an dem der Server den nächsten Teil des Indexes zum Client schickt.
Jetzt hat der Server den ersten Teil des Ansichtsindex gesendet. Der Client sucht sich jetzt die Dokumente die er anzeigen darf und zeigt diese. Wenn das was
er anzeigen darf nicht genug ist um auf den Bildschirm zu passen, dann fordert der Client den Server auf den nächsten Teil des Index zu schicken. Wieder
sucht sich der Client die Dokumente die er darstellen kann. Dieser Ablauf wiederholt sich bis der Bildschirm komplett aufgefüllt worden ist.
Jetzt stellen sie sich eine Ansicht mit 100.000 Dokumenten vor die alle Leser Felder haben und von denen sich nur einen verschwindend geringen Bruchteil,
sagen wir 5 Stück lesen dürfen. Der Client und der Server müssen den gesamten Index bis zum Ende durchgehen nur um herauszufinden das es trotzdem nicht genug
Dokumente sind um den Bildschirm zu füllen. Erst dann werden sie auf dem Bildschirm angezeigt. Das macht die Ansicht wirklich langsam.
Um dieser Falle aus dem Weg zu gehen sollten Sie es vermeiden Ansichten zu benutzen bei denen der Benutzer eine so geringe Anzahl von Dokumenten sehen wird
wenn es irgendwie möglich ist. Manchmal mag das aufgrund der Anforderung an die Anwendung unmöglich sein. dann sollten Sie zumindest darauf hinweisen, damit
sie später, wenn sich die Anwender über die mangelnde Performance beschweren "ich hab es euch ja gesagt" sagen können.
4. ein letzter Trick
Wenn man die Regel #9 benutzt (Autoren Felder sind auch Leser Felder) kann das sehr nützlich sein. Nehmen wir einmal an das sie eine Anwendung entwickelt
haben bei der die Leute Dokumente erstellen können, aber nur die Dokumente sehen sollen die sie auch erstellt haben. Das kann man sehr einfach erreichen
indem jeder Autoren Zugriff in der ACL auf die Datenbank bekommt. Die Benutzer die die entsprechenden Dokumente bearbeiten sollen werden in die
entsprechenden Autoren Felder eingetragen. Anschließend wird ein Leser Feld erstellt, das einen Wert enthält der keinen Benutzernamen darstellt. Weil das
Leser Feld nicht leer ist, ist das Dokument nicht für jeden zu sehen, Es ist auf die Personen beschränkt, die in dem Leser Feld eingetragen sind (erinnern
sie sich, hier steht kein echter Name). Aber es ist jetzt auch für alle Benutzer sichtbar, deren Namen in den Autoren Feldern stehen. Und da die Benutzer nur
Autoren Rechte in der Datenbank haben können Sie, auch dann wenn sie durch irgendeinen dummen Zufall auch andere Dokumente sehen würden, diese Dokumente
nicht ändern, weil sie in deren Autoren Feld nicht eingetragen sind.
Zusammenfassung
Das Sicherheits Modell von Notes ist eines der besten in der IT und es ist extrem verläßlich und sicher. Wenn, bezogen auf die eingebaute Sicherheit von
Leser und Autorenfeldern, die oben genannten Regeln angewendet werden wenn man eine Datenbank erstellt, sollte das helfen sichere Datenbanken zu
entwickeln
-
Falsch gedacht: man baut sich ein Feld (ich nenn das immer OUTDOOR ;) )und gibt nur diesem die Eigenschaft "Autorenfeld" mit. In diesem Feld steht dann z.Bsp. eine Rolle. Und nur die, die wo diese Rolle in der ACL haben, sind berechtigt...usw...
Lesen bildet. ;D
-
Ok ich bedanke mich bei Euch :)
-
Weil es schwer vorstellbar ist wenn ein Feld auf Autor gestellt ist das alle anderen Felder automatisch die Eigenschaft übernehmen.
Das Autoren-Feld ist nicht, wie die anderen Felder als einzelnes Feld für sich zu betrachten, sondern wirkt auf die gesamte Maske (bzw. auf die Dokumente, die mit dieser Maske erstellt wurden).
In der Designer-Hilfe ist das sehr gut beschrieben. Bernhard hat's dir ja schon nahe gelegt.
Außerdem gibt's hier im Forum jede Menge Threads die sich mit diesem Thema befassen. Benutze einfahc mal die Foren - Suche.
Axel
-
Davon abgesehen gibt es schon mindestens eine KFZ Verwaltung hier unter Tools (http://atnotes.de/index.php?topic=8025.0)
-
Danke für den Link ich hoffe ich kann damit was anfangen, wobei ich doch gerne selbst was erstellen möchte ist ja auch nur eine Projektarbeit im Rahmen des Studiums.
Ich habe mir die Schablone mal angesehen die ist sehr gut aber ich denke das ich selbst entwickeln werde.
Nun ich möchte jetzt eine Maske erstellen "kaufvertrag" diese soll dann Fahrzeugdaten und Kundendaten beinhalten... soweit kein Problem dann möchte ich einen Button einfügen der dann den Fahrzeugdatensatz aus der DB entfernt und diese Maske als Dokument druckt.
Für alle Tipps bedanke ich mich im Voraus MfG Rene
-
Das wird jetzt aber ein arges Gestoppel. Du müsstest hier erstmal ein Konzept vorstellen. Ich befürchte, da liegt noch einiges im Argen. Warum soll denn das Dokument aus der DB entfernt werden? Und wozu soll etwas gedruckt werden?
Ausserdem könntest Du Dir gerade ein Bein gestellt haben: Wer soll denn die Verkaufsangaben erstellen und dann das Fahrzeugdokument entfernen? Steht derjenige im Autorenfeld?
Bernhard
-
Also wohl doch lieber das Fahrzeugverwaltungstool nehmen?
Also das Konzept grob:
wir sind ein Onlinegebrauchtwagenhändler
der Admin soll sozusagen die Fahrzeuge erfassen
der Kunde soll sich die Fahrzeuge auf unserer DB ansehen können und dann zum Kauf vormerken
dann soll der Admin eine Mail bekommen wo er daraufhin den Vertrag erstellt und bei Abschluss soll das Fahrzeugdokument aus der DB gelöscht werden.
Und vieleicht zum Schluss noch so eine Art Zusammenfassung mit Verkaufszahlen
Nötig wären da wohl zwei DB: Kunde und Fahrzeuge nach meinen Kenntnisstand
-
Fängt schon gut an. Ich will selber entwickeln + prompt die ersten Fragen. Anscheinend ist kein Konzeot vorhanden + dann nur rudimentäre Kenntnisse von LoNo. Ob das gut gehen wird ? Wag ich mal zu bezweifeln.
-
Tja Sprung ins kalte Wasser, was bleibt mir anderes übrig
-
Gibt es eine Dokumentation zu dem Fahrzeugverwltungstool?
-
Dir bleibt vermutlich nix weiter übrig, aber der Firmenleitung. Dieser Versuch über einen Studenten ist zum Scheitern verurteilt. Scheinbar hat die Firma zuviel Geld, um derart "sparen" zu können.
Wir helfen Dir natürlich gerne weiter, können Dir aber hier keinen Kursus geben - und wollen Deiner Firma nicht Freeware liefern.
Bernhard
-
Gibt es eine Dokumentation zu dem Fahrzeugverwltungstool?
Vermutlich nicht, aber das würde auch nichts nützen, da diese DB für einen ganz anderen Zweck und eher als Demo gebaut wurde. Lediglich das Wort "Fahrzeug" passt zu Eurem Anliegen ;)
Bernhard
-
Definitiv kein Firmenprojekt sondern ein Lotus Kurs im Rahmen des Studiums unser Tutor ist im Urlaub und alle hängen in der Luft :( uns würden ja nur drei Masken und zehn Ansichten die vernünftig zusammenarbeiten reichen.
-
Es gibt so eine Datenbank für den Gebrauchtwagen Großhandel. die ist allerdings schon 5 Jahre alt und hat eine ganze Menge sehr spezieller Funktionen um Fahrzeug zu erfassen, zuzuordnen, einen Abgleich mit einer Web Datenbank zu machen und so weiter.
Da es die Firma für die das geschrieben wurde nicht mehr gibt und wenn ihr mir versprecht nicht wegen jedem Ding was ihr nicht versteht bei mir aufzuschlagen könnt ihr die zu Schulungszwecken haben.
Wenn ihr was kommerzielles daraus macht erscheine ich euch als Rachegeist.
-
Ok würden diese DB gerne haben und wirklich es ist absolut nicht für kommerzielle Zwecke.
Eine Frage noch wie kann von einer Maske zur anderen wechseln
welche Formel muss der Button enthalten?
Danke Gruß Rene
-
Eine Frage noch wie kann von einer Maske zur anderen wechseln
Willst Du einen Maskenwechsel oder einen Wechsel zu einem anderen Dokument? Das sind himmelweite Unterschiede. Wenn es um ein anderes Dokument geht: Wie wird das Dokument bestimmt?
Bernhard
-
Wir wollen einen Maskenwechsel per Button bei dem das geöffnete Dokument gleich mit in die nächste Maske übergeben wird.
-
Was ist die "nächste Maske" ? Also soll doch nur die Maske gewechselt werden, aber das Dokument soll das gleich bleiben?
-
Ich habe mal meine Kristallkugel geputzt und auch den Kaffeesatz von heute morgen befragt und ich glaube, er meint, dass, wenn er ein neues Dokument anlegt, Werte aus dem geöffneten übernommen sollen.
Das wäre dann die Maskenoption "Formel übernehmen Werte aus gewähltem Dokument". Außerdem muss in den entsprechenden Feldern als Vorgabewert der Name des Feldes rein, aus dem die Werte übernommen werden sollen.
Axel