Dynamics User Group - Archived Forums

The forums in this section of DUG are no longer accepting new post, but you can still get lots of value from the old posts here.
Please visit the active forums to comment/post new questions (choose which product you are interested in):


Über ODBC einen neuen Datensatz erstellen

Hallo und so

Grundlage:

Wir haben in Navision eine Tabelle, über welche man automatisiert eine Projektnummer generieren kann -> mittels f3 bzw "neu" kann eine solche generiert werden und stet alsdann für alle User zur Verfügung.

Diese Nummer wir jeweils vom letzten Wert um 10 inkrementiert -> P000100 war das letzte eröffnete Projekt, P000110 ist das nächste, welches mit f3 generiert wird.

Nun möchten wir mittels JAVA über JDBC ODBC genau diese Funktion ausführen.

Was bisher funktioniert:

- auslesen aller gewünschten Einträge (auch die Projektnummer)

- Updaten eines Projektfeldes (die Projektnummer ist hier explizit auschgeschlossen)

Hat irgendjemand eine Ahnung, wie man Navision-eigenen Code ausführen kann?

 

Vielen Dank schon mal für alle Antworten

Trushy

  • Hallo Trushy,

    welche Version setzt ihr ein?

    Gruß Jan

  • In reply to Jan Vorauer:

    Jan Vorauer

    Hallo Trushy,

    welche Version setzt ihr ein?

    Gruß Jan

     

    Hallo Jan

    Wir setzen Version 4.03 ein.

    -> Gegenfrage: hat dies einen Einfluss auf dieses Problem?

    Danke und Gruss

    Trushy

  • In reply to Rafi:

    Prinzipiell nicht, wenn ihr aber NAV 2009 einsetzen würde könnte man die Webservices nutzen. Die gab es unter NAV 4.03 aber noch nicht. Es ist nicht ganz einfach NAV-Code von außen anzustoßen - mit C/FRONT geht das aber damit kenne ich mich kein bischen aus, per ODBC geht es überhaupt nicht. Und per ODBC in die DB zu schreiben ist auch nicht so ganz die feine englische Art.

    Aber evtl. könnte man ja auch ein Ausweich-Szenario nutzen:

    Erstellt per Code eine neue Textdatei "NeuesProjekt.txt" (oder welche Dateiendung auch immer) in einem Verzeichnis ab. Schreibt nun in NAV eine Codeunit die dieses Verzeichnis ausliest und bei Vorhandensein einer Datei ein neues Projekt erstellt und evtl. eine Antwortdatei schreibt (mit der neuen Projektnummer(?)), die eingelesene Datei wird am Ende gelöscht oder wegarchiviert.

    Hängt diese Codeunit nun in den Objektaufrufplaner ein - oder noch besser lasst den NAS alle 2 Sekunden die Codeunit aufrufen.

    Das ist jetzt nur kurz hinskizziert und müsste noch genauer definiert werden, aber prinzipiell müsste das funktionieren, die meisten NAV-Schnittstellen die ich kenne arbeiten auf diesem Weg - Pollen ist mit NAV erheblich einfacher umzusetzen als NAV tatsächlich von aussen anzustoßen.

    Gruß Jan

  • In reply to Jan Vorauer:

    Jan Vorauer

    Prinzipiell nicht, wenn ihr aber NAV 2009 einsetzen würde könnte man die Webservices nutzen. Die gab es unter NAV 4.03 aber noch nicht. Es ist nicht ganz einfach NAV-Code von außen anzustoßen - mit C/FRONT geht das aber damit kenne ich mich kein bischen aus, per ODBC geht es überhaupt nicht. Und per ODBC in die DB zu schreiben ist auch nicht so ganz die feine englische Art.

    -> Das mit C/Front ist uns bekannt, ja. Allerdings sind wir uns noch nicht ganz sicher, oder besser gesagt hoffen wir auch auf Gegenteiliges, dass NAV-Code nicht von ausserhalb über JDBC-ODBC aufrufbar ist.

    Vielleicht noch zum Ziel unserer Arbeit: wir möchten ein zusätzliches Interface generieren, welches eine Arbeit in einer Listenansicht erlaubt (ist mit unserem NAV-Client nicht möglich). Und ein Punkt ist eben auch, ein neues Projekt zu generieren.

    Jan Vorauer

    Aber evtl. könnte man ja auch ein Ausweich-Szenario nutzen:

    Erstellt per Code eine neue Textdatei "NeuesProjekt.txt" (oder welche Dateiendung auch immer) in einem Verzeichnis ab. Schreibt nun in NAV eine Codeunit die dieses Verzeichnis ausliest und bei Vorhandensein einer Datei ein neues Projekt erstellt und evtl. eine Antwortdatei schreibt (mit der neuen Projektnummer(?)), die eingelesene Datei wird am Ende gelöscht oder wegarchiviert.

    Hängt diese Codeunit nun in den Objektaufrufplaner ein - oder noch besser lasst den NAS alle 2 Sekunden die Codeunit aufrufen.

    Das ist jetzt nur kurz hinskizziert und müsste noch genauer definiert werden, aber prinzipiell müsste das funktionieren, die meisten NAV-Schnittstellen die ich kenne arbeiten auf diesem Weg - Pollen ist mit NAV erheblich einfacher umzusetzen als NAV tatsächlich von aussen anzustoßen.

    Gruß Jan

    -> Hierfür müsste ich erst mal abklären, ob wir die Lizenz zum schreiben neuer Codeunits haben. Soweit ich momentan weiss, ist dies nicht der Fall, würde also bedeuten, dass alles ausserhalb NAV implementiert werden muss (ist eigentlich auch im Pflichtenheft definiert).

    Deshalb wären wir auch froh, wenn wir doch noch eine Lösung mit JAVA erarbeiten könnten.

    Gruss

    Trushy

     

  • In reply to Rafi:

    Hallo Trushy,

    wegen der fehlenden Möglichkeit mit ODBC (oder wegen mir auch JDBC-ODBC) NAV-Code anzustoßen bin ich mir ziemlich sicher. Aber wenn du hier was anderes hörst würde ich mich über eine kurze Meldung freuen. Wenn eure Schnittstelle aber so funktioniert wie ich mir das vorstelle (nämlich eine Möglichkeit mit der (SQL?-)-DB zu kommunizieren kann das eigentlich auch nicht klappen, da der Code in NAV nicht in Stored-Procedures oder ähnlichem vorhanden ist.

    Ihr könntet dann höchstens noch versuchen die o.g. Logik nachzubauen (also erhöhen der Nummer), müsstet dann aber dafür Sorge tragen, dass die Nummernserie selbst ebenfalls aktualisiert wird da es sonst knallen dürfte wenn ein Benutzer per Client versucht ein Projekt anzulegen. Ich weiß auch nicht inwieweit bei euch bei Anlage eines Projektes Vorgabedimensionen gezogen werden.

    Bzgl. meiner Anmerkung von oben dass ihr eine CU verwenden sollt: das würde natürlich alles auch theoretisch mit einem Report funktionieren...

    Gruß Jan

  • In reply to Jan Vorauer:

    Hallo Jan

     

    Es handelt sich um die vom Nav-Server zur Verfügung gestellte SQL-DB.

    Die Logik haben wir auch schon nachgebaut, das ist nicht das Problem (JAVA-mässig sind wir auf einem doch angenehmen Level), und auch das Einfügen klappt, aber den Zeiger können wir mit den aktuellenb Berechtigungen nicht überschreiben.

    -> Frage hierzu: ist es möglich, diese Berechtigung kurzfristig zu umschiffen? ansonsten ist dieser Ansatz wohl ebenfalls gestorben.

     

    Jan Vorauer

    Bzgl. meiner Anmerkung von oben dass ihr eine CU verwenden sollt: das würde natürlich alles auch theoretisch mit einem Report funktionieren...

    Den Ausdruck Report höre ich in Zusammenhang mit NAV nicht zum ersten mal, allerdings bin ich noch nicht weiter als zum "Hören" gekommen. Hast du hierzu ev. weitere Infos?

     

    Was ich zum Ankicken über ODBC gefunden habe (und mir auch in einem anderen Forum unter die Nase gerieben wurde):

    http://www.tipsdbits.com/Portals/0/Navision_Application_Server_Whitepaper.pdf

    Allerdings: Momentan Bahnhof wie ich das verwenden soll.

     

    Gruss

    Rafi

     

  • In reply to Rafi:

    Hallo Rafi,

    da ich von JAVA wenig bis keine Ahnung habe ist mir nicht ganz klar was ihr mit "können den Zeiger nicht überschreiben" meint. Das kommt nachdem ihr den DS bereits angelegt habt? Und jetzt wollt ihr ihn noch ändern?

    Ein Report ist in erster Linie mal eine Möglichkeit Daten anzuzeigen, eine Auftragsbestätigung die gedruckt wird ist ein Report. Allerdings kann man Reports auch nutzen um Daten zu ändern ohne einen Ausdruck zu generieren, in diesem Fall verhält sich ein Report ähnlich einer Codeunit.

    Der Navision Application Server ist im Grunde eine Art Client ohne Benutzeroberfläche. Man installiert ihn (als Windows-Dienst), verbindet ihn mit einem Mandanten der Datenbank und gibt ihm einen (oder mehrere) Startparameter mit. Weiter oben hatte ich so ein Szenario ja ebenfalls skizziert (der Navision Application Server wird gemeinhin mit NAS angekürzt). Ihn obigem Szenario würde man den NAS also mit einem Startparamer "ProjektAnlage" (nur Beispielhaft) starten. In der Codeunit 1 muss man dann die NASHandler-Funktion entsprechend abändern dass diese den o.g. Parameter liest. Hierdurch wird nun eine Codeunit gestartet in welcher Zeitgesteuert nach der Datei gesucht wird, ist eine vorhanden wird entsprechend ein Projekt angelegt und so weiter und so fort...Problem dürfte für euch nur sein, dass Ihr ja keine CU ändern könnt (und bei der CU 1 sollte man auch recht vorsichtig sein).

    Bliebe für euch also der Objektaufrufplaner - habt ihr den lizensiert? Falls ja könntet ihr eben diesen Report bauen und dann durch den OAP zeitgesteuert aufrufen lassen.

    Ich glaube nach wie vor nicht, dass Ihr den Zugriff per JAVA schaffen werdet...und ihr habt die Native DB im Einsatz, richtig? Oder tatsächlich einen SQL-Server darunter?

    Gruß Jan

  • In reply to Jan Vorauer:

    Hallo Jan

    Mit dem Zeiger meine ich den Eintrag, wo man die als zuletzt generierte Projektnummer finden kann (in Java würde man dem "Zeiger", "Pointer" o.ä. sagen).

    Wenn ich deine Erklärung zum Report richtig verstanden habe und auch die Dokumente richtig übersetzt habe, dann liegt das mit dem CU-ändern auch nicht drin. D.h. eine Lösung mittels Report tut nicht.

    Wir haben die Möglichkeit, gewisse Änderung an der Datenbank vorzunehmen, den Objekt Designer kann ich auf jeden Fall öffnen. Allerdings: da krieg ich momentan noch nicht mal einen Überlick hin was wir damit erreichen könnten.... $

    Aber bevor du dich jetzt hier abmühst mir das zu erklären werde ich morgen nochmals mit meinem Arbeitskollegen zusammensitzen und abklären, ob wir ev. für das nachträgliche Überschreiben  des Zeigers die DB-Verbindung wechseln können: der User startet mit normalen Berechtigungen, festgelegt in der ODBC-Verbingung der Systemverwaltung, im Moment der Neugenerierung wir diese Verbindung aber kurzzeitg mit einer höherberechtigten überschrieben (quasi eine zweite Verbindung hinterlegen).

    Da wir hier nur von einem sehr kleinen Betrieb sprechen und die meisten von ODBC keine Ahnung haben, sollte dies eigentlich möglich sein- aber die Entscheidungskompetenz liegt klar nicht bei mir Wink

    Falls dieser Ansatz aber nicht genehmigt werden sollte, melde ich mich wieder und- werde dann auch bereits selber einiges über den Objekt-Designer gelesen haben und nicht mehr ganz so Newbiemässig daherkommen *g*.

    Danke und Gruss

    Rafi

  • In reply to Rafi:

    Hi Rafi,

    alles klar. Ok, dann wünsche ich mal viel Erfolg und wenn ihr das hinbekommt würde ich mich über eine kurze Meldung hier freuen :-)

    Gruß Jan

  • In reply to Jan Vorauer:

    Hi Jan

    mir ist eben in den Sinn gekommen, dass ich dir hierzu noch eine Antwort schuldig bin :-)

    Wir haben jetzt eine "Symptom"-Lösung programmiert, und zwar stellen wir die Funktion von Navision in unserer Applikation nach. Einziger Wehrmutstropfen: die User bekommen über die ODBC Schnittstelle minim erweiterte Rechte. Was aber nicht ganz so schlimm ist, da die wenigstens überhaupt wissen was ODBC ist, geschweige denn eine Ahnung haben, wie sie das einsetzen könnten *g*.

    Das Problem ist daher gelöst, wenn auch nicht ganz optimal.

     

    Gruss und nochmals Danke für deine Hilfe

    Rafi

  • In reply to Rafi:

    Hallo,

    eine kurze Frage von mir. In welcher Tabelle werden die Datensätze erzeugt und werdensie auch weiterhin dort verarbeitet? Ich kenne unschöne Effekte, dass mittels ODBC Steuerzeichen wie Zeilenumbrüche etc.oder für NAV ungültige Werte ihren Weg in NAV Tabellen gefunden haben, die dann bei Ausführen im NAV Client unschöne Ergebnisse bis hin zum berühmten Crash des Native Servers geführt haben.

    Wenn man die Daten unbedingt mit ODBC ins System bringen will, sollte man sie zumindest in eine eigene "Eingangstabelle" schreiben, von wo sie mit C/AL Code in die produktiven Tabellen überführt werden.

     

Related