Kompilieren des Datenbankscriptes

[basile]

Liebe Dominoknechter,

ich arbeite gerade an Datenbankscripten und ärgere mich:
wenn ich meine Änderungen sehen will, komme ich bei einer lokalen Datenbank damit klar, wenn ich das Datenbankscript komplett lösche, meinen Designer und Client schließe, danach den Designer wieder aufmache, den Code in das Datenbankscript reinpaste, speicher, schließen, Client öffnen et voila -> Änderungen sind da. Das ist etwas umständlich (erinnert mich an die 90er, die "IDE" auf dem Amiga ).
Wenn ich dieses Vorgehen aber bei einer DB auf dem Server mache, werden die Änderungen nicht übernommen, erst am nächsten Tag sehe ich die. auch ein komplettes Kompilieren des Codes nutzt nix.
Bin leider kein Admin, habe schon gelesen, dass ein Serverneustart das Script zum kompilieren zwingt.
Gibt es noch andere Wege???

Viele Grüße

Udo

[umi]

Moin

- DB Script in eigene Library auslagern und nur die Aufrufe im DB Script platzieren. ?
- Nach einem Recompile den Client neustarten ?

[Peter Klett]

Wieso sollte ein Serverneustart ein Script neu kompilieren?

Datenbanken mit geschlossenem Design würden dann zerstört, weil das nicht mehr vorhandene Script neu übersetzt wird?

Kann alles nicht sein. Was ist Dein Problem? Funktionieren Änderungen der Gestaltung nicht sofort? Entwickelst Du in Schablonen oder direkt in der Datenbank? Hast Du die geänderte Datenbank nach der Änderung im Client geschlossen?

[koehlerbv]

Sehe ich auch so: Hier ist etwas oberfaul. Und es könnte durchaus schon die Beschreibung sein.
Was verstehst *Du* eigentlich unter "DatenbankScripten"?
Warum löschst Du diese komplett? Das ist recht unüblich / unnötig.
Was willst Du dort erreichen?
Wie äussert sich das genau, dass Du Code irgendwohin hineinkopierst und dann nicht sehen solltest? Und was sollte das mit dem Kompilieren zu tun haben? Ohne entsprechende Werkzeuge siehst Du eh keinen kompilierten Code, sondern immer nur den Quelltext.

Vielleicht helfen uns ein paar aussagekräftige Schirmschüsse.

Bernhard

[jo@chim]

Genau Probleme in der Art hatte ich im Zusammenhang mit dem Problem "Frontend DB schliessen, andere Replik öffnen", das ich gepostet hatte:
Das Script wird als Call aus meiner Library im Datenbankscript aufgerufen - und Änderungen kamen regelmässig erst dann zum Tragen, wenn ich Notes geschlossen und den Cache gelöscht hatte (8.5.3)

(Muss gerade an die schöne Charakterisierung denken, die mal ein Entwicklerkollege gebracht hat: "Notes ist weiblich. Du wirst sie nie völlig verstehen. Es kommt darauf an, zu lernen mit ihr umzugehen"  )

[koehlerbv]

Solange die betreffende DB geöffnet ist - mit dem Client oder mit dem Designer (!) - werden Teile des DBScripts entweder gar nicht erst angesprungen (Initialize, PostOpen) oder Änderungen können nicht wirksam werden. Das DB-Script wird (u.a.) mit dem Öffnen der DB in den Cache geladen. Nochmals: Das gilt auch, wenn die DB "nur" im Designer noch offen ist.

Bernhard

[jo@chim]

Notes-Versteher 

[koehlerbv]

Nö, nur ein Faultier: Was ich weiß, darauf kann ich nicht mehr reinfallen. Das gilt auch für meine Manie, allen momentan unnützen Ballast sofort wieder von mir zu werfen (Cache-Files, unbenötigte DBs im Designer usw. usf.). Wenig Aufwand und dafür sehr, sehr entspanntes Arbeiten.

Bernhard

[Peter Klett]

Das Problem mit der geöffneten Datenbank im Designer dürfte bei sinnvoller Vorgehensweise nicht vorkommen, denn hier entwickelt doch wohl niemand ernsthaft in Datenbanken, sondern ausschließlich in Schablonen, oder ... ?

Im Designer kann die Schablone, sogar das betroffene Element, z.B. eine Scriptbibliothek, offen sein. Dort Script ändern, speichern, in den Client wechseln, Gestaltung aktualisieren, evtl. noch geöffnete Datenbank schließen und neu öffnen. Tut genau das, was man gerade in das Script getippt hat. Ist es nicht das, was man wollte, zurück zum Designer und der Cursor steht noch an der gerade vermurksten Stelle. Besser ist das wohl kaum zu lösen.

[koehlerbv]

Peter, Du unterliegst einem irrtum, einem Gerücht. Das ist nicht richtig.

Bernhard

[Peter Klett]

Peter, Du unterliegst einem irrtum, einem Gerücht. Das ist nicht richtig.

Bernhard

Meinst Du wirklich? Dann habe ich die letzten Jahre wohl was falsch gemacht, oder ich arbeite nicht mit Notes. Bei mir funktioniert das genau so, wie ich beschrieben habe. Kann ich Dir vorführen, wenn Du mal in der Nähe bist ...

[Tode]

Ich muss sagen, bis vor kurzem habe ich auch so gearbeitet wie Du, Peter, habe mich aber von Bernhard von einer -imho- effizienteren Arbeitsweise überzeugen lassen:
Wir entwickeln tatsächlich in einer Datenbank. Das hat verschiedene Vorteile:

1. jeder beteiligte Entwickler weiss immer, wo der aktuellste Entwicklungsstand ist
2. das ständige refresh design fällt weg (für jede kleine Änderung)
3. man muss sich nicht um Testdokumente, etc. z.B. Für Ansichtsdesign kümmern.
4. webentwicklungen kann man direkt testen, bei ntfs ist das ja schwierig.

Hat man einen bestimmten Stand erreicht, dann wird daraus via Db Kopie (ohne Dokumente) ein Template, das der Kunde erhält.

Wir fahren damit ganz gut, nur im gerade geschilderten Fall ist das natürlich ein kleiner Nachteil...

[Peter Klett]

Hallo Torsten,

ich kenne Euer Umfeld nicht, was für Datenbanken Ihr baut und in welcher Komplexität die eingesetzt werden. Bei uns würde solch ein Szenario absolut unproduktiv sein, da der Fokus darauf besteht, ein komplexes System mit möglichst wenigen Schablonen zu entwickeln.

Seit Februar diesen Jahres bauen wir ein neues System (mein drittes Großprojekt, macht richtig Spaß). Vor kurzem ging Version 1 in Produktion. Etwa 2000 Datenbanken aus 17 Schablonen. So etwas kann man nicht mit einer Datenbank (je Schablone) entwickeln und testen. Ohne nachzusehen besteht mein lokales Testsystem aus mindestens 30 Datenbanken, und wenn man darin die Interaktivität der Datenbanken, die aus der gleichen Schablone erzeugt wurden, weiterentwickeln und testen will, geht das nicht auf dem von Dir beschriebenen Weg, denn dazu müssen mindestens zwei Datenbanken aus der gleichen Schablone aktualisiert werden.

Die Aktualisierung einer Datenbank aus einer Schablone geht nun wirklich schnell (ALT D-U-G, Server auswählen, Enter), sicherlich schneller, als laufend die Datenbank im Designer zu schließen und bei der nächsten Änderung wieder die Stelle zu suchen, an der man gerade gearbeitet hat. Und bei übergreifenden Änderungen (z.B. Änderung in der zentralen Schablone, die die einzelnen Schablonen mit übergreifend eingesetzten Elementen versorgt), startet man den Design-Task.

Nach langer "Alleinherrschaft" habe ich endlich eine sehr gute Verstärkung bekommen. Die Zusammenarbeit klappt auch technisch sehr gut, da wir einen Satz Schablonen auf dem Entwicklungsserver liegen haben, von dem jeder Repliken auf seinem lokalen Testserver vorhält. Es wird abgesprochen, wer welches Element bearbeitet, und Ergebnisse werden schnellstmöglich auf den gemeinsamen Server zurückrepliziert.

Du hast mich also nicht überzeugt, aber wichtig ist, dass jeder den für sich richtigen Weg findet, und davon gibt es ja immer mehrere ...

[gstueb]

Ich denke auch, dass die Vorgehensweise immer vom Umfeld abhängt.

Bei komplexen Umgebungen, in denen Anwendungen aufeinander zugreifen und ggf. parallel aktualisiert werden, hat man i.d.R. eine eigene Testumgebung und wird überwiegend mit Schablonen arbeiten.

Beim aktualisieren einer einzelnen Anwendung ist meiner Ansicht nach Bernhards Weg der praktikablere. Die Original-Schablone will man ja nicht ändern, solange die neue Version in Entwicklung ist. Und wenn die nächste Version reif für den Produktiv-Einsatz ist, wird sie zur Schablone für die alte Version.

Aber egal - das schöne an Notes ist ja, dass  jeder das für sein Umfeld passende Konzept verwenden kann.

Zurück zum eigentlichen Problem:

Das Problem mit dem Datenbankscript kenne ich so auch nicht. Meiner Erfahrung nach ist oft die Ausführung der Funktion "Werkzeuge / LotusScript vollständig neu compilieren" notwendig/sinnvoll, insbesondere wenn Änderungen an Klassen vorgenommen wurden. In sehr seltenen Fällen musste ich alle Notes Clients (Notes, Designer, ggf,. Admin) beenden und neu starten, damit Änderungen aktiv wurden.

Grüße,
Gregor

[basile]

Hallo Leute,

Wow, danke für die vielen Antworten, hätte nicht gedacht, dass ich so eine Diskussion lostrete. Kann mich erst heute melden, da ich nur halbtags in der Firma bin.
Also ich schildere nochmal den Fall: ich arbeite direkt an der Produktivdatenbank.
bei einer lokalen Datenbank muss ich wirklich per STRG-A, STRG-x das komplette Datenbankscript löschen (und in Notepad++ reinkopieren), Datenbankscript speichern, Designer ind Client schließen, Designer öffnen, das rauskopierte Zeugs per STRG-V wieder ins Datenbankscript pasten und speichern, Designer schließen. Erst nach einem Öffnen des Clients sehe ich die Änderungen. -> dieses Vorgehen habe ich im Netz gefunden. Stelle weiß ich nicht mehr.
Beim Arbeiten am DB-Script in einer DB auf dem Server sehe ich die Änderungen leider erst am nächsten Tag. Da hilft auch mein (etwas kompliziertes) Vorgehen nix.
@umi: Recompile nutzt auch nix, sehe die Änderung dann auch erst am nächsten Tag. Leider kann man nicht einzelne Scripte kompilieren, sondern immer nur die ganze DB. Das dauert lang und setzt alle Scripte auf eine andere Signatur.
@koehlerbv: die Routine muss angesprungen werden, ich bearbeite die QueryDeleteDocument und setze eine MessageBox rein, die mir die CodeVersion anzeigt. Damti habe ich dann die Kontrolle, was passiert - oder auch nicht.
@Peter: ich entwickle auch direkt in der DB. Ich habe gemerkt, dass beim Arbeiten mir der Schablone Agenten z.B. nicht immer korrekt anspringen, es dauert länger, Testdokumente muss ich immer neu anlegen, ausserdem kann man aus jeder DB jederzeit ein Template kochen (lassen).
Mich ärgert eher was anderes an der Lotus-Entwicklung: bei puren C++/Java/WhatEver-Projekten habe ich normale Textfiles für den Code. Meinetwegen 10000 Stück. Diese kann ich aber bequem mit z.B. Git verwalten und jederzeit jeden Stand wiederherstellen, bzw. Entwicklungszweige für ein Feature komplett unabhängig entwickeln/verwerfen. Das geht mit Lotus nich besonders toll - binäres Format . Auch die Enwicklung im Team ist damit schwieriger-Absprachen (obwohl ich Einzelkämpfer bin). Ich arbeite mit Git in einer anderen Firma und bin (nach anfänglicher steiler Lernkurve) überzeugt von dem Vorgehen und der Sicherheit.

Viele Grüße aus dem sonnigen Göttingen

Udo

[Tode]

Du wiederholst leider nur das "geht nicht"... Lies bitte, was man Dir schreibt: So lange die Datenbank IRGENDWO geöffnet ist, werden sich Änderungen am Datenbankscript nicht auswirken. Deine "Copy- Paste- Orgie" ist vollkommen unnötig und auch Fehleranfällig.
Geh einfach folgendermassen vor (wenn Du nicht in einer Schablone entwickeln willst, denn dann gibt es das Problem wirklich nicht):

1. Ändere Dein Datenbankscript und speichere es
2. Entferne die Datenbank aus dem Designer ODER schliesse den Designer komplett
3. Schliesse alle Referenzen auf die Datenbank im Client (offene Dokumente, offene Ansichten, einfach alles
4. Öffne die Datenbank wieder -> Das Datenbank- Script wird neu eingelesen und Du siehst den neuen Code.

Das kann nur dann "problematisch" sein, wenn Du die Datenbank z.B. als Homepage des Clients festgelegt hast oder sie in der Homepage als Frame anzeigst, dann musst Du tatsächlich u.U. den Client neu starten, um Deine Änderung zu sehen.

Eine Messagebox bringt Dir gar nix, für sie gilt natürlich genau das gleiche wie für den restlichen Code... So lange die Datenbank offen ist, wird sich die Messagebox nicht ändern.

[basile]

Lieber Tode,

Du hast Recht, ich kann mich auch nur wiederholen. Wenn ich den Designer und den Client schließe (als Programm und nicht nur die DB da drin) sind ja alle meine lokalen Refenzen auf die DB weg. Beim Neuöffnen sollte ja eben das DB-Script neu eingelesen werden. Aber genau das tut es nicht. Daher meine Copy-Paste Orgie bei lokalen Datenbanken / bzw. meine Hilflosigkeit bei DBs auf dem Server.
Ich habe ja auch schon danach gesucht und die einzige Lösung, die ich im Netz gefunden habe war, den Server neu zu starten, das entfällt für mich, da das der Produktivserver ist und ich kein Admin bin. Außerdem ist diese Lösung hier auch verworfen worden.

Viele Grüße

Udo

[Peter Klett]

Beim Arbeiten am DB-Script in einer DB auf dem Server sehe ich die Änderungen leider erst am nächsten Tag. Da hilft auch mein (etwas kompliziertes) Vorgehen nix.

Das kann ich mir nur dann vorstellen, wenn bei Euch irgendetwas zwischendurch passiert. Z.B. Entwicklung auf einer Datenbank, die mit dem produktiven Server über Nacht repliziert, oder doch eine Entwicklung in einer Produktiv-Schablone, und der nächtliche Designtask aktualisiert die produktive Datenbank.

@Peter: ... Testdokumente muss ich immer neu anlegen ...

Unsinn, Du hast dann eine Testdatenbank mit Testdokumenten und legst darüber die weiterentwickelte Schablone. Davon verschwinden nicht die Dokumente.

Auf jeden Fall ist mir die Notwendigkeit zu Deinem Copy-und-Paste-Verfahren in den letzten fast 20 Jahren noch nicht untergekommen.

[thkn777]

@basile
Ich kenne derlei Probleme mit dem DB-Script auch nicht 

ABER: Notes kann manchmal zickig sein. Wie wär's mit dem "blöder Fehler - blöde Lösung" Ansatz?

Lösch' doch mal in der Cache.NDK alles, was bei "DREI!" nicht auf dem Baum ist. Tip: man kann die Cache.NDK auch direkt aus Notes als DB öffnen und muß sie nicht im Filesystem löschen.

Zweite Idee:
Probier' das mit dem DB-Script mal in einer neu angelegten, leeren Schablone (oder DB) aus. Vielleicht ist Deine aktuelle DB ja einfach nur "wackelig" an der Stelle?

Viel Erfolg,
Th.