[Gelöst]Fehlermeldung: Navision hat ein Problem festgestellt

Hallo zusammen,

aus welchen Gründen kann eine solche Fehlermeldung erscheinen?

"Microsoft Business Solutions hat ein Problem festgestellt und muss beendet werden...
Falls Sie ihre Arbeit nicht gespeichert haben gehen Daten verloren...

Microsoft Business Solutions neu starten (x)"

und dann noch ...Fehlerbericht senden oder nicht.

Die Meldung erscheint immer beim Buchen eines Auftrags .
Sie erscheint an einem PC, bei allen Usern, bei jedem Auftrag.

Navision habe ich bereits schon mal komplett neu installiert, jedoch ohne Erfolg.

Der Fehler tritt ab und zu auch an anderen Arbeitsplätzen auf.
Ich habe versucht an 2 verschiedenen PC's eine gebuchte Rechnung zu drucken - dabei kam derselbe Fehler,
wobei bei diesen PC's der Druck von gebuchten Lieferscheinen wiederum ohne Abbruch erfolgte.

Navision-Version 3.70 (3.70.A)

Vielen Dank im Vorraus

Zuletzt geändert von littleBunny am 5. Oktober 2010 13:59, insgesamt 1-mal geändert.

Das ist ganz schwierig zu beantworten, zumal ihr ja eine sehr alte Navision-Version verwendet
Steht - beim Rechner, bei dem der Fehler aufgetreten ist - vielleicht irgend etwas Aussagekräftiges im Windows Anwendungsprotokoll?

Nun ja, sooooo alt ist die Version 3.70 ja nun auch wieder nicht. Es sind ja noch genügend Versionen 2.x im Einsatz.

Aber nun zu dem Problem: Da der Fehler nur auf einem Rechner auftritt, muss es etwas mit seiner Konfiguration zu tun haben.
Was ist das denn für ein Rechner / Betriebssystem? Ist evt. eine extra Software installiert, die auf den anderen Rechnern nicht vorhanden ist?

Es sind da schon die tollsten Dinge aufgetreten.

Nun ja, sooooo alt ist die Version 3.70 ja nun auch wieder nicht. Es sind ja noch genügend Versionen 2.x im Einsatz

Ergänzung:
Passiert auch mit 5.x und 2009 Classic

Ein Klassiker, der mir immer wieder mal unter die Finger kam:
Es wurde mittels RecordRef / FieldRef versucht, ein Code/Text-Feld auszulesen, welches mit einer Maximal-Länge von weniger als 5 Zeichen definiert wurde.

Absturz bis Version 5.0 SP1 garantiert. (In NAV 2009 SP1 ist der Fehler behoben worden, jedoch gibt es da dann andere Fallstricke mit RecRef/FldRef.)

Lösung/Workaround:
Entweder die entsprechenden Felder auf mindestens 5 Zeichen vergrößern und per C/AL-Code die maximale Eingabe-Länge prüfen,
oder vor dem Zugriff mittels RecordRef/FieldRef über die Field-Tabelle prüfen, ob das Feld groß genug für einen Zugriff mit RecordRef/FieldRef ist.

Ein technisches Update auf NAV2009SP1 würde euch vor (mir z. Zt. im Detail nicht näher bekannte) weitere Probleme stellen.

Es wurde mittels RecordRef / FieldRef versucht, ein Code/Text-Feld auszulesen, welches mit einer Maximal-Länge von weniger als 5 Zeichen definiert wurde

Interessant!
Wie ist das genau gemeint? Verstehe ich nicht ganz.

Danke

Es wurde mittels RecordRef / FieldRef versucht, ein Code/Text-Feld auszulesen, welches mit einer Maximal-Länge von weniger als 5 Zeichen definiert wurde.

Absturz bis Version 5.0 SP1 garantiert.

Kriege ich mit NAV5.0 SP1 Build30488 nicht nachvollzogen. Oder meinst du etwas Anderes?

Code:

RecRef.GETTABLE(Tab);
FldRef:=RecRef.FIELD(FeldNoVonFeldCode2);
message('%1',FldRef.Value);

Kriege ich mit NAV5.0 SP1 Build30488 nicht nachvollzogen. Oder meinst du etwas Anderes?

Okay, ich präzisiere: Absturz garantiert, wenn man direkt mit dem RecordRef (also ohne FieldRef) lesend darauf zugreift:

Code:

RecRef.GETTABLE(Tab);
message('%1',RecRef.FIELD(FeldNoVonFeldCode2).Value);

Hinweis: Ab NAV2009 SP1 führt (in bestimmten Buildnummern) diese Variante in jedem Fall (auch bei größeren Feldern) zum Absturz.
Die Verwendung eines FieldRefs ist somit zwingend erforderlich.

Das glaube ich ja nicht.
Nun wird mit einiges klar.

Aber das ist doch ein Bug? Da wird MS doch hoffentlich einen Fix liefern?

Gruss

Ich habe RecRefs mitunter auch ohne FieldRefs implementiert.

Darf ich dann also nochmal überarbeiten.

@Timo: Danke für die Info.

Gibts nochmehr davon die dir gerade einfallen?
Sag es lieber gleich, sonst wird das nächste Community-Treffen ein Bug-Meeting!

mfg
winfy

Zuletzt geändert von winfy am 17. September 2010 09:28, insgesamt 4-mal geändert.

littleBunny , bist du noch im Thema?

Aber das ist doch ein Bug? Da wird MS doch hoffentlich einen Fix liefern?

Dies kann man als Fehler sehen, oder aber auch als "It's by Design" betrachten, denn für den Zugriff auf Feldebene sind ja nunmal die FieldRefs vorgesehen.

Falls es dich beruhigt: Ich darf auch alle meine Tools überarbeiten, da ich gerne und häufig mit RecordRefs (und wo es ging auch ohne FieldRef) gearbeitet habe.

Okay, ich präzisiere: Absturz garantiert, wenn man direkt mit dem RecordRef (also ohne FieldRef) lesend darauf zugreift:

Code:

RecRef.GETTABLE(Tab);
message('%1',RecRef.FIELD(FeldNoVonFeldCode2).Value);

Klappt auch so. Ähm ich meine: es stürzt nicht ab :) Ist dann wohl Zufall, dass meine Build damit klar kommt.

Scheinbar gibt es Buildnummern (unabhängig von der Major-Version), wo es funktioniert, und welche, wo es teilweise oder auch gar nicht funktioniert.

Falls es funktioniert: Glück gehabt!
Falls nicht: Jetzt wisst ihr, woran es liegen kann.

Ich werde meine bisherigen Erfahrungen mal zusammenstellen und an Microsoft schicken.

Das Problem ist mit Build 30906 schon lange behoben.

982621 5.0.30906
The Dynamics NAV 5.0 client crashes when you run C/AL code that contains the RecRef.field.value statement in Microsoft Dynamics NAV 5.0 Service Pack 1 with Update 2 installed

Gruss

Das Problem ist mit Build 30906 schon lange behoben.

Vielen Dank für die Info, jedoch erklärt das immer noch nicht, warum ich dies auch unter NAV2009 SP1 reproduzieren kann (Buildnr. ist mir gerade nicht bekannt.)

Vielen Dank für die Info, jedoch erklärt das immer noch nicht, warum ich dies auch unter NAV2009 SP1 reproduzieren kann

.. und auch nicht, wieso meine kleinere Build nicht crasht. Vielleicht müssen ja noch andere Voraussetzungen erfüllt sein

Aber wurscht; Hauptsache ist schon, dass man eine mögliche Ursache kennt.

Das Problem ist mit Build 30906 schon lange behoben.

982621 5.0.30906
The Dynamics NAV 5.0 client crashes when you run C/AL code that contains the RecRef.field.value statement in Microsoft Dynamics NAV 5.0 Service Pack 1 with Update 2 installed

Gruss

Beachte: Die Korrektur gilt nur für 5.0 SP1 Update 2.

Beachte: Die Korrektur gilt nur für 5.0 SP1 Update 2.

Aber dann ist der Fix doch in 2009 SP1 auch enthalten?
Oder?

Beachte: Die Korrektur gilt nur für 5.0 SP1 Update 2.

Aber dann ist der Fix doch in 2009 SP1 auch enthalten?
Oder?

Für 6.0 SP1 gab es - der Beschreibung nach - ein eigenes Fix in KB 977063

Edit: ist doch eigentlich völlig egal, es hat doch nichts mit dem Problem von littleBunny zu tun ...

Hallo,

sind in der Datenbank vor kurzem einzelne Objekte (Tabellen, Codeunits) geändert worden? Es kommt manchmal vor, dass durch Programmänderungen leichte Inkompatibilitäten auftreten, die zu Abstürzen führen.
Ein "Compile All" wirkt hier oft Wunder, aber Vorsicht, wenn deine Objekte schlecht gepflegt sind, dann kann das zu einem nicht mehr funktionierenden NAV führen. Daher erst einmal mit dem Objekt-Stand in einer Test-DB probieren.

Wenn das ganze nur auf einem Rechner passiert. Ist die Festplatte des Rechners voll?
Wenn du in der Ereignisanzeige schaust, wirst du dort normalerweise eine Absturzmeldung des Clients finden. In der Textmeldung oder in den HEX-Daten findet man oft eine Meldung "Fehler XX in Modul YY", damit kann man den Fehler weiter eingrenzen.

Hallo,

ja bin noch dabei Nathalie - nur grad bissl viel zu tun :)

Also die 3.70 benutzt ein Kunde von uns -
welches Bts er benutzt, muss ich noch rauskriegen ansonsten würde ich sagen er soll die Build No mal prüfen,
und ob seine Festplatte voll ist.

Sonst jemand noch einen Vorschlag?

@ fiddi: Ist diese Ereignissanzeige kompliziert?
Ich weiss nicht ob der Kunde das hinbekommt ;) ??
Bei den meisten sind die Kenntnisse doch sehr begrenzt -.-

Vielen Dank an Euch alle

Ich kann mich erinnern, dass wir mit 3.7 ein solches Problem auch hattten.
Dort wirkte eine Neuinstallation aller Client-Drucker wahre Wunder

Gruss

Dort wirkte eine Neuinstallation aller Client-Drucker wahre Wunder

das klingt doch nicht schlecht :)

gleich mal ausprobieren lassen...