[Gelöst] Artikelanalyseansicht - Funktionalität deaktivieren

Hallo zusammen,

wir haben ständig bei Artikelbewegungen die Fehlermeldung "Die Tabelle Artikelanalyseansicht ist von einem anderen Benutzer gesperrt". Wir nutzen die Artikelanalyseansicht-Funktionalität momentan gar nicht. Kann man das irgendwie komplett deaktivieren?

Ich bin versucht, einfach den Code im OnRun der Codeunit 7150 "Update Item Analysis View" auszukommentieren; aber gibt es evtl. eine sauberere Möglichkeit?

Zuletzt geändert von InfoWissler am 11. Februar 2014 13:41, insgesamt 1-mal geändert.

Hallo,

ist auf der Analyseansichtskarte das Feld "Bei Buchung aktualisieren" markiert?
Dann würde ich dort zuerst ansetzen.

Gruß
Marion

Hallo,

wir haben einen Datensatz in der Tabelle und bei dem ist der Haken nicht gesetzt (alle anderen Felder scheinen mir auch auf den InitValue gesetzt zu sein).

Beim Buchen wird im Standard im Codeunit die Funktion UpdateAll ausgeführt und das erwähnte Feld gefiltert.

Code:

IF DirectlyFromPosting THEN
  ItemAnalysisView2.SETRANGE("Update on Posting",TRUE)
IF ItemAnalysisView2.ISEMPTY THEN
  EXIT;

Wenn dann keine Ansicht übrigbleibt, wird das Codeunit normalerweise also verlassen.
Eventuell wird der Boolparameter DirectlyFromPosting nicht korrekt übergeben, dann funktioniert das nicht mehr. Dazu müsste man die Funktionsaufrufe prüfen (Codeunits 23,33,80,90,1013,5704,5705,5815,5980 sowie ggf. "selbstgestrickte").

Bei uns steht in der 7150 nur folgendes:

Code:

IF DirectlyFromPosting THEN
  ItemAnalysisView2.SETRANGE("Update on Posting",TRUE);

ItemAnalysisView2.LOCKTABLE;
...

Wenn bei uns auch die IF ISEMPTY THEN EXIT - Abfrage dazwischen wäre, dann wäre das wahrscheinlich die Lösung. Ich kann mir gut vorstellen, dass das ein Bug ist, der in einem SP oder so behoben wurde (wir haben wirklich noch NAV 2009 ohne SPs - wollen bald auf 2013 gehen) Ich habe jetzt aber auch auf Anhieb keinen KB-Artikel gefunden. Ich spiele die Abfrage aber jetzt ein, das sollte bei uns die Fehlermeldungen im Lager drastisch reduzieren.

Wenn bei uns auch die IF ISEMPTY THEN EXIT - Abfrage dazwischen wäre, dann wäre das wahrscheinlich die Lösung. Ich kann mir gut vorstellen, dass das ein Bug ist, der in einem SP oder so behoben wurde […]

Wenn die fehlt, ist das eher ein grundliegendes Problem. Diese Abfrage ist schon in der RTM Version ohne SP von Anfang an mit dabei gewesen.

Bei uns steht in der 7150 nur folgendes:

Code:

IF DirectlyFromPosting THEN
  ItemAnalysisView2.SETRANGE("Update on Posting",TRUE);

ItemAnalysisView2.LOCKTABLE;
...

In der 4er Version war der Code noch so. Sicher, daß du im richtigen Forum gepostet hast? Habt ihr vielleicht eine alte Version mit einem technischen Update auf 2009? Ansonsten würde ich vermuten, ihr habt kein vollständiges Update bekommen. Was natürlich äußerst kritisch ist, weil man dann schlecht entscheiden kann, was noch alles vergessen bzw. falsch gemerget wurde. In dem Fall solltet ihr auf jeden Fall mit eurem Partner sprechen, wie das denn sein kann.

P.S. Was steht in der Versionsliste der Codeunit?

Vielen Dank für die Hinweise! Die Versionsliste ist NAVW15.00. Da hat wohl jemand beim Kopieren von Code aus einem veralteten Objekt ins neue Objekt nicht korrekt abgeglichen, sondern einfach überschrieben, das wird dann hoffentlich ein Einzelfall gewesen sein. Ist aber schon ein wenig gruselig...

Ob es in der 5.00 noch so war, kann ich nicht sagen. Hab hier nur eine 5.00.01 vorliegen und dort war es schon korrigiert.

Das heißt aber auf jeden Fall, daß ihr noch keine 2009er habt, allenfalls technisch. Ob jetzt zusätzlich auch noch ein Mergefehler (oder sogar mehrere) vorliegt, kann man aus der Ferne nicht sagen. Ich würde das auf jeden Fall mal mit eurem Partner besprechen.

Die Versionsliste ist NAVW15.00.

In Version 5.00 fehlte das

Code:

IF ItemAnalysisView2.ISEMPTY THEN
  EXIT

noch.
Falls also nur technisch upgedatet wurde, wäre das für die Version vom Codestand her korrekt. Trotzdem sollte die Abfrage natürlich eingebaut werden, um die Perfomance zu verbessern.
Falls auch die Applikation angeblich auf NAV 2009-Stand sein soll, dann wäre das, wie schon gesagt, sehr kritisch zu bewerten.

Die 5.00 hatte aber diverse Schwierigkeiten. Und ein Update auf SP1 wäre kein übermäßiger Aufwand. Von daher hätte ich jetzt nicht damit gerechnet, daß man seinen Kunden auf 5.00 stehen läßt. Gerade vor dem Hintergrund, daß ja anscheinend ein technisches Update durchgeführt wurde.

Filter doch mal, ob es in eurer Datenbank Objekte mit NAVW15.00.* oder sogar NAVW16* gibt.

Von daher hätte ich jetzt nicht damit gerechnet, daß man seinen Kunden auf 5.00 stehen läßt.

So selten war das aber nicht. Als uns damals aufgefallen ist, dass unser Update auf NAV5SP1 nur technisch war, hat uns unser Partner versichert, dass die 5er-Objekte viel besser wären . Beim Update auf 2009R2 wollten sie dieselbe Praxis anwenden.

Von daher hätte ich jetzt nicht damit gerechnet, daß man seinen Kunden auf 5.00 stehen läßt.

So selten war das aber nicht. Als uns damals aufgefallen ist, dass unser Update auf NAV5SP1 nur technisch war, hat uns unser Partner versichert, dass die 5er-Objekte viel besser wären . Beim Update auf 2009R2 wollten sie dieselbe Praxis anwenden.

was soll man dazu noch sagen, außer mit dem kopf zu schütteln

Der Grund lag wohl darin, dass unser Partner den Aufwand (und die Kosten?) gescheut hat, sein AddOn für jede 5er bzw. 2009er Version upzudaten und von MS zertifizieren zu lassen. Nach den Erfahrungen mit dem Update auf 5SP1 habe ich ja geahnt, was uns beim Update auf 2009R2 erwartet - nämlich 2009er Objekte im 2009R2-Mantel und der Versuch, uns ein weiteres Mal für dumm zu verkaufen. Das endete mit viel Streit und damit, dass ich das komplette Update auf 2009R2 halt selbst gemacht habe.

Manchmal ist es aber auch keine böse Absicht, sondern einfach Unwissenheit. Update sind oft ungeliebte, langwierige Aufgaben, gerade bei stark individualisierten Lösungen. Man kann aber auch sehr viel dabei lernen. Von daher werden oftmals die unerfahrenen Mitarbeiter beim Partner in erster Instanz daran gesetzt. Wenn sich der Partner danach aber nicht die Zeit nimmt, daß Ergebnis von einem erfahrenen Mitarbeiter querprüfen zu lassen, dann kommt es nachher ganz übel beim Kunden hoch. Das ist sicherlich für niemanden eine schöne Situation.

Verstehe nicht, was du mir damit sagen willst.

Und beim verhandelten Update auf 2009R2 zu versuchen, dem Kunden 2009er Objekte unterzuschieben, ist für mich nicht nur böse Absicht.

Ich will sicherlich niemanden verteidigen oder so. Dafür kenne ich die Situation einfach zu wenig. Ich wollte nur allgemein sagen, daß solche Dinge manchmal auch nicht mit Absicht, sondern aufgrund von Unwissenheit geschehen. Ein relativ aktuelles Beispiel ist 2009 R2, hier kommt von vielen die Aussage, daß sich im Vergleich zu 2009 SP1 nur technisch etwas geändert hätte. Das ist so aber nicht ganz korrekt, es wurden auch einige wenige Objekte marginal angepaßt. In den allermeisten Fällen wird das keine Relevanz für den Betrieb von NAV haben, aber streng genommen gehören zu einem echten Update auf 2009 R2 auch immer diese Objekte.

es wurden auch einige wenige Objekte marginal angepaßt

Das ist nett ausgedrückt ; ich habe um die 100 mit 16.00.10 in der Version. Einige davon waren auch neu (Kreditkarten).

Aber ich verstehe, was du meinst - das scheidet hier jedoch aus, denn dafür hätte unser Partner auch noch alle 2009SP1-Objekte "übersehen" müssen.