.CreateFromTemplate

[jr]

Hallo,

bei meinem Problem mit den mehrfachen Ini-Einträgen konnte mir leider niemand helfen. Jetzt habe ich aber etwas anderes herausgefunden. Der Fehler tritt nur dann auf, wenn die Datenbank mit der CreateFromTemplate-Methode aus NotesDatabase erstellt wird.

Gibt es da irgend welche Beschränkungen? Laut Designer-Hilfe macht die Funktion exakt das Gleiche, wie wenn ich eine neue Datenbank auf Basis eines Template-Datei erstelle. Aber das ist wohl nicht so. Die manuell erstellen Datenbanken arbeiten ganz normal. Bei den programmatisch erstellten Datenbanken aber werden Notes-Ini-Einträge nicht mehr überschrieben, sondern immer wieder neu hinzugefügt, so dass die Einträge mehrfach auftauchen.

Hier der Code, mit dem die Datenbanken erstellt werden:

Code

Set db = tmplDB.CreateFromTemplate(sServer, sPath, True)
If (Not(db Is Nothing)) Then db.Title = "Projekt " & sIdentNo
...

Sonst passiert da eigenltich nichts. Hat da irgend jemand schon Erfahrungen damit gemacht? Muss ich bei der Erstellung noch irgend etwas beachten?

Gruß,

Joachim

[koehlerbv]

Ich musste jetzt erstmal nachlesen, was Du in diesem Posting bei dieser Überschrift auf einmal mit doppelten INI-Einträgen hast. Okay, jetzt habe ich es nachgelesen, hilfreich war dieser "offene Querverweis" aber nicht.

Ich arbeite in etlichen Applikationen mit automatisch aus einem Template erstellten User-Datenbanken, in einigen (wenigen) Fällen machen diese auch Einträge in die NOTES.INI. Das von Dir beschriebene Verhalten ist mir (bei einigen hundert Datenbanken) aber noch nicht begegnet. Das will aber nichts heissen.
Kannst Du dieses Verhalten auf bestimmte Client-Versionen (bzw. Domino-Versionen, insofern diese die neuen DBs erstellen) festmachen?
Da die NOTES.INI ja an die NotesSession gebunden ist, darf es nicht sein, dass eben diese Doppeleinträge in der NOTES.INI ermöglicht bzw. selbst erzeugt.

Bernhard

[jr]

Hallo Bernhard,

danke für die schnelle Antwort. Sorry, ich hätte den Link auf den Eintrag angeben sollen. Wird sofort nachgeholt:

Doppelte Einträge in der Notes.Ini: http://atnotes.de/index.php?topic=32821.0

Die Applikation sieht wie folgt aus: In einer Datenbank liegen unter anderem einzelne Projektdatenblätter. Für jedes dieser Projektdatenblätter kann auf Knopfdruck eine Art Projekt-Datenbank aus diesem Template erzeugt werden. Dies wird schon seit fast zwei Jahren so gemacht und hat immer funktioniert. Mittlerweile gibt es beim Kunden über 100 solcher Projektdatenbanken. Am Anfang waren das ziemlich viele, jetzt passiert das aber nur noch ab und zu (vermutlich ist das schon eine Weile so, nur noch nicht aufgefallen). Doch irgend etwas hat sich geändert, denn seit einiger Zeit passiert der oben beschriebene Effekt. Und da dies sowohl bei meinem Kunden, als auch bei mir so ist, muss ich wohl davon ausgehen, dass ich da irgend etwas gemacht habe, was Notes nicht mag.

Bei meinem Kunden ist die Client- und Server-Version 6.5.4. Ich habe es mit Client 6.5.4 und 7.0.1 und mit Server 7.0 getestet, aber das gleiche Ergebnis.

Am Template selbst scheint es nicht zu liegen, denn ich habe es auch mit anderen Datenbanken versucht, da alle meine Datenbanken gleich arbeiten. Trotzdem ist irgend etwas anders als noch vor einem halben Jahr.

Im Prinzip dürfte es nicht möglich sein, egal wie, doppelte Ini-Einträge zu erzeugen. Ich habe sonst auch noch nie irgend etwas über einen solchen Effekt gelesen. Ist schon irgend wie komisch...

Gruß,

Joachim

[jr]

Noch was...

Wenn man bei der Datenbank ein @Command([DesignRefresh]) macht, dann funktioniert wieder alles normal. Komisch...

Gruß,

Joachim

[jr]

Problem erkannt...

Jetzt funktioniert es wieder. Das Problem habe ich behoben, aber passieren darf so etwas trotzdem nicht. In der übergeordneten Funktion war ein "On Error Resum Next" eingebaut. Und der Befehl "db.Title = ..." hat zwar den Titel geändert, aber trotzdem ein Fehler produziert. Daraufhin wurde die Funktion einfach beendet und nicht mit dem nächsten Befehl weitergemacht. Dies hatte dann den Effekt, dass die Datenbank irgend wie korrupt war und die doppelten Ini-Einträge erzeugte.

Egal wie, es darf eigentlich keine Situation eintreten, die einen solchen Effekt hat. Ist schon seltsam. Der "db.Title = ..." wurde an einen andere Stelle verschoben und der "On Error..." entfernt und schon funktionierte wieder alles.

Also, hauptsache, dass das Problem gelöst ist. Warum es überhaupt aufgetreten ist, hab' ich zwar nicht verstanden, aber ich muss ja auch nicht alles wissen... 

Gruß,

Joachim

[koehlerbv]

Um jetzt dahinter zu kommen, wo jetzt der Fehlr in Deinem Code liegt, braucht es sicher nicht nur den kompletten Code, sondern auch noch eine Beschreibung des gesamten Kontextes.

Das ist aber nicht der Kern: Du verwendest "On Error Resume Next". Gleichzeitig schreibst Du:

Warum es überhaupt aufgetreten ist, hab' ich zwar nicht verstanden, aber ich muss ja auch nicht alles wissen...

Diese Verbindung ist ein absolutes "no-no". "On Error Resume Next" sollte darf man niemals verwenden, es sei denn, man weiss sicher, was passiert und wie darauf zu reagieren ist. Alles andere ist programmiertechnisch "Russisches Roulette", wie Du ja selbst erlebt hast: Du verlierst komplett die Kontrolle.

Denkbar wäre beispielsweise folgendes Konstrukt:

On Error Goto NormalErrorHandler
... Code ...
'Jetzt wird es speziell:
On Error Goto IchBefuerchteFehler1024
... Code ...
'Schweiss abwisch' - es ist gut gegangen:
On Error Goto NormalErrorHandler
... weiter im Code ...
'Ende Gelaende:
Exit Sub

'Hier kommen die ErrorHandler:
NormalErrorHandler:
... "Normale" Fehlerbehandlung, normalerweise Abbruch der Routine ...
Exit Sub

IchBefuerchteFehler1024:
If Err = 1024 Then
...korrigiere die Situation - ueberpruefe das Resultat!!!
Resume Next   '<- UND NUR SO !!!
Else
Goto NormalErrorhandler
End If
Exit Sub

Ich hoffe, das Grundprinzip konnte ich verständlich machen (und ganz so simpel ist es reell nicht zu kodieren!). Wenn es nicht verstanden wurde: Verwende prinzipiell nicht "Resume Next".
"Resume Next" ist vergleichbar mit folgender Situation: Du merkst bei Vollgas, dass es Dich aus der Kurve trägt. "Resume Next" heisst: Okay, ich habe es festgestellt, aber ich mache weiter so ...

Bernhard

[jr]

Hallo Bernhard,

dem kann ich so nicht ganz zustimmen. Wenn der Code steht, und das hatte er seit über zwei Jahren, dann sorgt eine On Error -Klammer dafür, dass selbst bei einem noch so unwahrscheinlichen Fehler, der Code weiter läuft und alles andere trotzdem ausgeführt wird. In meinem Fall heißt das, nach dem Datenbank anlegen, den Titel setzen, Konfigurationsdokumente kopieren, ACL anpassen und Datenbank öffnen. Das hat er auch alles gemacht (bis auf den Datenbanktitel) und der Kunde konnte nach einem weiteren Design-Refresh wie gewohnt weiter arbeiten. Von der Datenbank wurde seit Monaten keine neue Version mehr ausgeliefert. Wahrscheinlich habe ich irgend etwas schon vor langer Zeit verändert, das sich erst jetzt bemerkbar gemacht hat. Und obwohl ich normalerweise alles ausführlich dokumentiere, habe ich dazu nichts gefunden. *schäm*

Also ich glaube nicht, dass ich alle Eventualitäten im Voraus weiß. Wenn der Code reibungslos läuft, dann sorgt der 'On Error Resume Next' dafür, dass der Benutzer auch bei nicht vorhergesehenen Problemchen weiterarbeiten kann.

Natürlich hast Du recht, dass ein Abfangen mit 'On Error Goto ...' eleganter ist, wenn man dann eine schöne Fehlermeldung ausgibt und dann den Code mit Resume Next weiterlaufen lässt. Das ist sicherlich in den meisten Fällen der Fall, aber hier hätte es mir auch nichts genützt, weil der Benutzer mit "Userdefined error" nichts hätte anfangen können. Und, ehrlich gesagt, bei einem db.Title erwarte ich einfach keinen Fehler...

Aber wo ich wirklich falsch lag: Bisher bin ich davon ausgegangen, dass ein 'On Error...' immer nur in der aktuellen Funktion gilt. Das dies aber anscheinend auch noch in einer tieferen Funktion, in einer ganz anderen Bibliothek, gültig ist, war mir nicht bewusst. Da werde ich in Zukunft besser aufpassen müssen.

Nochmals vielen Dank für Deine Unterstützung.

Bis zum nächsten Mal,

Joachim