Shutdown Prozedur

Hallo miteinander, ich brauche dringend eure Hilfe. Gibt es eine Möglichkeit ein Navision-Objekt zu starten, automatisch vorgeschaltet, bevor der “Dienst Navision” auf einem NT-Server beendet wird ? Ich müsste z.B. einen Dataport starten, bevor die Datenbank geschlossen wird. Das gleiche gebrauche ich nach dem Starten des “Dienstes Navision”. Ich arbeite mit Navision 2.01. Ich würde mich freuen, schnell von euch zu hören. Rolf

Hi Rolf! Wär mal interessant zu wissen, was Du damit (den Dataports) anstellen willst … [:D] Es gibt in NAVISION zwei Möglichkeiten beim Beenden oder Starten des Clients div. Aktionen auszuführen, auch den Start eines Dataports:

  • Im Hauptmenü (oder jeder anderen Form)in “OnQueryCloseForm” (beim Start “OnOpenForm”)
  • In Codeunit 1 in “LoginEnde” (beim Start “LoginStart”)
    Objekte können lediglich innerhalb eines Clients ausgeführt werden. Es gibt - leider ? - keinen Trigger derart “OnServerShutdown” oder “OnServerStartup”. Gruß, Jörg

Hi Jörg, meine Frage betrifft nicht das Starten / Beenden eines Clients, sondern das des Servers. Das mit Codeunit 1 ist mir schon klar. Wozu? : Ich will den Datenendstand aus einer eigenen User-Tabelle exportieren und dann alle exportierten Sätze in der eigenen User-Tabelle löschen. Die exportierten Daten müssen gesammelt an eine andere DB (nicht Navision) weitergegeben werden. Kann ich nicht irgendwo auf die Server.exe Einfluss nehmen oder von außen die Navision-DB bearbeiten ? Gruß Rolf

Hi Rolf! Wie gesagt: Objekte (also auch Dataports) können nur im Client ausgeführt werden. Es gibt aber kein Ereignis derart, daß der Server das Beenden des Dienstes an den Client meldet, der daraufhin ein Objekt ausführen könnte. Prinzipiell ist dies möglich: - Objekte können mit einer URL verknüpft werden, diese URL kann “von außen” aufgerufen werden und somit das Objekt ausgeführt werden (ab NA 3.x, Login muss passiert werden!) - Innerhalb WinNT muss der Starten bzw. Beenden des Dienstes überwacht werden um dann bei den entsprechenden Ereignissen per URL das Objekt zu starten. Probleme: - Eure Version ist 2.01, also keine Objekt-URL - Ich bin nicht sicher, ob NT solche Eingriffsmöglichkeiten bietet … Lösungsansätze: - Das Problem kann nur über den Client gelöst werden (unmittelbar oder mittelbar via URL) - Optionen sind “OnClose”, “LoginEnde”, etc. - Alternativ wäre auch eine Zeitsteuerung denkbar (gibt’s schon “OnTimer” in 2.01 ?) - Ggf. ist ein “technisches” Update auf 3.60 ratsam - Kann sich die andere DB z.B. via ODBC die Daten NAVISION beschaffen? Gruß, Jörg

Hallo Jörg, kannst Du mir bitte erklären, was …ist ein “technisches” Update auf 3.60 bedeutet ? Heisst es etwa nur : Server-Exe u. Clients austauschen ? Wäre nett, wenn Du mir hierzu noch etwas sagen könntest. Gruß Rolf

quote:


Heisst es etwa nur : Server-Exe u. Clients austauschen ?


Exact! [8D] Bedeutet - in unserem Fall - eine Datenbank mit Objektstand der Version NF2.60.D auf einem NA3.60.A Server (und natürlich auch 3.60 Clients). Die “Anwendungen” bleiben somit die alten, jedoch basiert das ganze auf “neuer” Technik, inkl. neuer Features: “HotCopy”, Objekt-URL, XML-Dataport, uvm. Vorgehen bei einem solchen tech. Update: - Voraussetzung: Aktuelle Lizenz die die “neue” Version freigibt! - Datensicherung der “alten” DB (komplett, wichtig sonst [xx(]) - “alten” Server deaktivieren - Installation eines “neuen” Clients auf Server-PC (neue Lizenz!) - “Neuen” Client direkt mit “alter” DB verbinden, Aufforderung zur Konvertierung bestätigen, bei Erfolg: - “Neuen” Server installieren, mit konvertierter (“neuer”) DB verbinden und starten (neue Lizenz!) - “Neue” Clients installieren - Voila! (Eine “Rückkonvertierung” ist danach nicht mehr möglich, in diesem Fall muss einen neue Datenbank mit Hilfe der Datensicherung auf Basis der “alten” Version aufgebaut werden. Versuchen “alte” Clients sich mit der “neuen” DB zu verbinden, so erhalten diese eine Fehlermeldung.) Unbedings vorher Testen ob - in Deinem Fall - der Sprung von NF2.01 auf NA3.60 funzt [;)] Gruß, Jörg

Hallo Jörg! Das ist eine interessante Variante, da wir wegen unserer zahllosen Änderungen an den diversen Objekten eher keine Lust auf einen “Voll-Upgrade” NF2.60 → NA3.60 haben… Ist 3.60 eigentlich voll kompatibel zum 2.60 Objektstand, oder kann es da zu Problemen kommen, weil vielleicht manche C/AL Funktionen in 3.60 ein subtil anderes Verhalten an den Tag legen? [:p]

Hallo Heinz! Diese “techn. Updates” führen wir schon seit zig Jahren durch, eben weil wir weder Zeit noch Geld für ein aufwendiges Update aufbringen wollen, solange die “alte” Anwendung noch unseren Ansprüchen genügt. Und wenn wir schließlich doch “richtig” updaten, dann ist dies bei uns stets ein Re-engineering-Prozess bei dem alte/individuelle Funktionen nicht einfach übernommen werden, sondern neu konzipiert, realisiert oder weggelassen werden, so daß eine aktuelle Version eigentlich immer eine neue Version ist, die die Geschäftsprozesse optimal abbildet. Doch zu Deiner Frage: Wir haben damit ausschließlich positive Erfahrungen gemacht [:)] Bei unserem letzten “Sprung” (2.60 Objekte auf 3.60 DB) habe ich festgestellt, daß einige schnell aufeinanderfolgende Datei-Operationen (CREATE/CLOSE/OPEN/CLOSE/…) “Problemchen” bereiteten, die ducrch ein simples YIELD in den Griff zu bekommen waren (CREATE/YIELD/CLOSE/YIELD/OPEN/YIELD/CLOSE/YIELD/…) Ansonsten konnte ich bisher keine Mängel/Fehler feststellen [:D] Wie gesagt: Vorher testen ist wichtig! So z.B. haben wir vor einiger Zeit eine neue Technik unter eine NF1.2 DB bauen wollen, und bei den Tests von NF2.50 (damals aktuellste Version) erhebliche Proble festgestellt, so daß wir nur auf 2.01 gegangen sind. (Inzwischen ist ja algemein bekannt, daß 2.50 grundsätzlich ein paar Macken [}:)] hat.) Gruß, Jörg

Vielen Dank für die Info, Jörg!

Hi Jörg, ich werde mich mal erkundigen, was ein techn. Update auf 3.60 für uns bedeutet, von den Kosten und vom Aufwand. Erst einmal vielen Dank für den Tipp. Rolf Rolf

Hallo, ich wollte mich nur kurz einmischen. So ganz ohne “Problemchen” geht es naemlich nicht! Einfach mal folgendes lesen (betrifft vor allem diejenigen, die nur ein technische Update machen wollen): http://www.navision.net/forum/topic.asp?TOPIC_ID=4934&SearchTerms=post+and+print Seit November 2002 ungeloest! Evtl. kann Joerg ja auch mal zu diesem Problem kurz was sagen. Der muesste es ja auch haben. Gruesse Walter

Tach zusammen, Hi Walter! Hmmm … hab’ die Topic gerade gelesen … dieses Problem ist mir selbst noch nicht aufgefallen, auch hat sich noch kein Anwender über ein solches “Verhalten” beschwert … werd’ mal 'n paar Tests machen … Gruß, Jörg

Ja gibt’s denn des wirklich [:0] Hab’s eben ausprobiert … und tatsächlich tritt dieses “Phänomen” - je nach Umstand - auf … Ist hier bloss keinem aufgefallen, da im Tagesgeschäft nur gebucht und nur am Monatsende gedruckt wird … ist mir auch bei meinen Tests nicht aufgefallen … Ha, wär doch gelacht wenn wir uns diesen “Bug (?)” nicht irgendwie hinbiegen … [:D] Fasziniert, Jörg [:p]

Interessante Sache… Wenn der Bug durch den Einbau einer MESSAGE zum Verschwinden gebracht werden kann, reicht vielleicht auch das von Jörg in anderem Zusammenhang bereits erwähnte YIELD[?]

Das “Buchen & Drucken”-Problem hat sich eben so erledigt: 1. Streiche Aufruf Codeunit “Verkauf-buchen + drucken” via RunObject-Property im Menü “Buchen” 2. Setzte Aufruf Codeunit “Verkauf-buchen + drucken” via Code IF NOT CODEUNIT.RUN(CODEUNIT::"Verkauf-buchen + drucken", Rec) THEN; im Menü “Buchen” Gibt vielleicht noch andere - elegantere [:)] - Lösungen (YIELD?) - die hier tut’s … jedenfalls bei uns … Gruß, Jörg P.S: Ich schätze mal das Ganze hat mit dem boolschen Rückgabewert der Codeunit zu tun (der im “Standard” nicht abgefangen wird) und somit ein FALSE u.U. als ERROR auf der Form interpretiert wird, was zum Schließen der Form führt … hab im Moment keine Zeit mir das mal im Debugger anzusehen …

Hehe, vergiss den Debugger, Joerg. Ich habe mich schon Stunden damit beschaeftigt ohne wirklich auf den Fehler zu kommen. Das kann nur aus der FIN.EXE stammen. Das Problem ist hier, dass, je nachdem was gerade gemacht wurde, ein Fehler bezueglich der Einkaufsseite auf der Verkaufsseite “hochkommt” und umgekehrt(z.B. beim (Buchen und) Drucken der Verkaufsrechnung kommt die Fehlermeldung Belegart::Einkaufsrechnung, Belegnummer::XXX ist nicht vorhanden). Kann also nur aus der EXE kommen. Das ganze geht jetzt aber “Off-Topic”. Wer Lust hat… wir koennen das andere Topic ja wieder aktivieren. Gruss Walter

quote:


Originally posted by stryk
P.S: Ich schätze mal das Ganze hat mit dem boolschen Rückgabewert der Codeunit zu tun…


Unsere CU 82 Verkauf-buchen + drucken hat keinen Rückgabewert… Kann’s sein, daß das nur in der deutschen Version so ist (wir haben die österreichische)? Vielleicht kann man den Rückgabewert überhaupt eliminieren? Ist aber wirklch schon sehr OT - wie wär’s mit einem neuen Thread?

quote:


C/SIDE: [{Ok} :=] CODEUNIT.RUN(Number [, Record])


Auch wenn nicht unmittelbar eine Funktion mit bool. Rückgabewert aufgerufen wird, so gibt CODEUNIT.RUN immer einen Wahrheitswert zurück, zumindest beim Aufruf via Code … Gruß, Jörg