Office: (Office 2007) Ãœberlauf beim Anwender, bei mir nicht.

beim lesen lohnsummenimport und schreiben in TMPLOHNSUMMEN.
Bei welchem code weiß ich nicht. Bei mir läuft das ja durch.

 

Beispiel:
Code:

Die Zeilennummern lassen sich z.B. mit den kostenlosen MZ-Tools per Mausklick einfügen.

Ich hoffe, der Fehler weiß, dass er nicht vorkommen darf?

Wenn bei dir der Fehler nicht auftritt, bitte doch einfach den Kollegen, mal die Fehlerbehandlung auszukommentieren.
Dann seht ihr doch, an welcher Stelle es zu dem Fehler kommt!

Das halte ich für effektiver, als wenn Du so lange testest, bis es Dir irgendwann mal gelingt den Fehler zu provozieren.

 

Woher weißt Du das so genau? Im Rahmen der Mammutprozedur gibt es einen Import aus einer Textdatei (den ich allerdings inhaltlich nicht zuordnen kann/möchte). Und Dir ist die Stelle des Fehlers unbekannt.

Finden Importe ins Frontend oder ins Backend oder idealerweise in ein Temp_BE statt? Der Glaube, gleiche Daten zu haben, ist nicht immer berechtigt.

Zusätzliche Denkfrage: Wenn ein Import mit Fehler an unbekannter Stelle abgebrochen wird, hat man auch eine hohe Wahrscheinlichkeit, dass dadurch inkonsistente Daten vorliegen oder der Datenzustand "undefiniert" unvollständig ist. So etwas wie eine Transaktion habe ich beim Überfliegen nicht erkennen können. Gibt es Strategien, wieder einen geordneten Datenzustand herstellen zu können?

Praxisfrage: Ist der Fehler beim Anwender reproduzierbar? Auch, wenn bei ihm Dein offenes FE mit auskommentierter Fehlerbehandlung eingesetzt wird?

Nicht nur nebenbei zum Thema Mammutprozedur:
Da empfiehlt sich ein Refactoring! Kleine übersichtliche Prozeduren vereinfachen auch das Finden von Fehlern, was augenscheinlich wird, wenn eine Prozedur nur genau eine bestimmte Aufgabe ausführt.

Der Code "erfüllt den Tatbestand der Körperverletzung": Sprungmarken, undeklarierte Variablen und Objekte, selbst eine Laufvariable i taucht aus dem Nichts aus. Die Codelesbarkeit ist mangelhaft, daraus leiten sich dann auch die Probleme bei der Fehlersuche ab.

 

Auch ich würde dir gern vorschlagen, den Code neu zu schreiben, denn er enthält viel überflüssigen Ballast.
Beispiele: Code:

lässt sich ersetzen durch: Code:

Code:

lässt sich ersetzen durch: Code:

was bereits ein paar Zeilen zuvor zu finden ist.

Und wahrscheinlich könnte man noch weitere Optimierungsmöglichkeiten finden, wenn man den Code komplett lesen und prüfen würde.

 

Hallo
Wenn Du die gleich Version des FE und des BE hast
dann würde ich danken
1. Prüfe wirklich ob ihr, bei den Verweisen etc. die gleichen Versionen habt !
z.b bei
VBA (VBE6.DLL ) / Access (MSACC.OLB ) / DAO(dao360.dll) und MsJet40.dll /Msado15.dll etc.
2. Da der User Ja eine MDB (accdb) hat, ob er nicht etwas am Code Verändert hat (bewust oder unbewust)

deshalb bekommen bei mir die User nur eine ACCDE (mde) die sie nur mit der Option /runtime Starten Können
respektiv eine ACCDR

 

Woher weißt Du das so genau? Im Rahmen der Mammutprozedur gibt es einen Import aus einer Textdatei

Weiß ich weil ich debugged habe. Übenahmeart = 1 von Textdatei in Tabelle Lohnsummenimport.
Ãœbernahmeart = 2 von Lohnsummenimport in tmplohnsummen.
Finden Importe ins Frontend oder ins Backend oder idealerweise in ein Temp_BE statt?

Ins Backend

Praxisfrage: Ist der Fehler beim Anwender reproduzierbar? Auch, wenn bei ihm Dein offenes FE mit auskommentierter Fehlerbehandlung eingesetzt wird?

Ja. Er bekommt Ãœberlauf, ich nicht.Auskommentiete Fehlerbehandlung habe ich noch nicht versucht. Am Besten ich schaue bei ihm vorbei.

Der Code "erfüllt den Tatbestand der Körperverletzung": Sprungmarken, undeklarierte Variablen und Objekte, selbst eine Laufvariable i taucht aus dem Nichts aus. Die Codelesbarkeit ist mangelhaft, daraus leiten sich dann auch die Probleme bei der Fehlersuche ab.
Du hast völlig Recht. Aber wer bezahlt das? Funktioniert doch bis jetzt. Wenn ich vorschlagen würde das ganze neu zu schreiben Kosten einige Mannmonate, klar das die Kaufleute sagen nein danke. Funktioniert doch, bis auf das Problem mit dem Lohnsummen einlesen.
Auch ich würde dir gern vorschlagen, den Code neu zu schreiben, denn er enthält viel überflüssigen Ballast.
Du hast Recht. Aber wer bezahlt das?


Prüfe wirklich ob ihr, bei den Verweisen etc. die gleichen Versionen habt !
Kann ich machen, aber warum?
Datentyp Speicherbedarf Wertebereich
Long (lange Ganzzahl) 4 Bytes -2.147.483.648 bis 2.147.483.647
Double
(Gleitkommazahl mit doppelter Genauigkeit) 8 Bytes - 1,79769313486231E308 bis -4,94065645841247E-324 für negative Werte; 4,94065645841247E-324 bis 1,79769313486232E308 für positive Werte.

da hat sich nichts geändert, egal welche Version, warum bekommt er Überlauf und ich nicht?. Ausser mit irgend eimem Update gibt es einen Fehler.

Da der User Ja eine MDB (accdb) hat, ob er nicht etwas am Code Verändert hat (bewust oder unbewust)

Das ist nicht der Fall. Der Anwender kommt nicht in den Code der ist paawortgeschützt. Er hat das bestimmt nicht gemacht. Das ist ein Kaufmann, der seine Arbeit machen will, der fummelt nicht am Code rum.

 

Der Import findet ins Backend statt?
Code:

Vergleiche klick mich. Dann läuft Dein Code im Backend?

Ich würde nach wie vor auf ein Datenproblem tippen, also einen einen einzelnen Fehler in einer der Datendateien.

 

Moin cobol,

Genau so ist es: ..... bis jetzt ....

Irgendwann kommt der Punkt, da hast Du so viel "umzu gestrickt" das Dir alles, aber auch alles um die Ohren fliegt.
Aber wahrscheinlich musst Du diese Erfahrung erst machen .... und dann geht Dir der Anwender richtig auf die Nerven, weil er nicht mehr arbeiten kann.

Wenn Du Dich im Forum umschaust wirst Du erkennen, dass hier viele Leute absolut auf der fachlichen Höhe sind, glaube denen doch einfach.

Und noch einen Tipp. Benutze doch einfach die Zitat-Funktionen etc. des Forums.
Deine Post lassen sich ähnlich schwer lesen wie Dein Code.

@ebs und @anne: Respekt für Eure Geduld

Viele Grüße Stefan.

 

Genau das ist doch der springende Punkt, worauf Du hier schon einige Mal
angesprochen wurdest.
Solange Deine Fehlerbehandlung aktiviert ist, stocherst Du (und wir) weiter im Nebel...

 

Moin cobol,

noch einmal für mich:
- hast Du Dir die ACCDE (inkl. Backend) vom Kunden/Anwender einmal zuschicken lassen und auf Deinem Rechner ausprobiert mit einer IMPORT-Datei des Kunden/Anwenders ?
- hat der Kunde/Anwender noch einmal eine "frische" Version von Dir bekommen die bei Dir läuft ?

Ich denke auch, wie Ebs in #22 schon angemerkt hat, das Deine Importspezifikation nicht zur Import-Datei passt. Evtl. wurde die Datei vom User geändert.
Da gibt es seitens Access komische unverständliche Meldungen, die erst einmal nicht auf die Spezifikation schließen lassen.

Ich kann Dir nur wärmstens empfehlen, den Code komplett durchzunummerieren und mit einer Fehlerbehandlung (jedes Form, jedes Modul - siehe #17) auszustatten.
Das geht total schnell per Klick mit dem MZ-Tool.
Evtl. kommst Du damit schon einmal weiter, weil das Teil Dir genau sagt, wo es "rumst".

Ansonsten wie schon angesprochen, die "alte" Fehlerbehandlung auskommentieren und anschauen ..... beim Anwender.

Stefan.

 

Ich würde das Teil sehr gerne umschreiben. Der Kunde ist wahrscheinlich nicht bereit das zu bezahlen, deswegen habe ich das gar nicht vorgeschlagen.
Das ist nicht mein Code, das hat ein Vorgänger geschrieben. Ich weiß, dass der furchtbar ist.

der Zweig wird in dem Fall nicht ausgeführt. Wie ich schon schrieb Übernahmeart = 2. Kopieren von Lohnsummenimport nach tmlohnsummen, da tritt der Fehler auf.

Ãœbernahmeart = 1 Lesen Textdatei
transfertext funktioniert. Code im Backend, Tabelle im Backend, veknüpfte Tabelle. Villeicht weil es keine Importspezifikation gibt.

Ich werde das mal durchnummerieren und dem Anwender schicken.

 

... und der ganze Formular- und Meldungskram auch?
Code:

Solche "total normalen" Gestaltungen muss man dann auch nicht erwähnen?
Wieder mal ein Beispiel dafür, dass man alles, aber wirklich auch alles für möglich halten muss.
Gibt es bei Dir auch 5 Millionen Euronen, wenn man richtig rät?

 

Natürlich im Frontend. Ich habe mich verschrieben. Entschuldigung.

 

Moin Cobol,

gibt es schon neue Erkenntnisse?

Mir ist gerade so in den Sinn gekommen:
hast Du Dein Entwickler-Frontend mal auf dem User-Rechner laufen lassen und Dir mal angesehen (per Remote) ob hier auch der Fehler auftritt ?
Also ums auskommentieren der Fehlerbehandlung wirst Du nicht rumkommen ..... aber *Smilie

Viele Grüße Stefan

 

\@Ebs17 Du brauchst nicht raten. Du kannst auch lesen was über dem Code steht.

Ich werde einen Termin mit dem Anwender machen und mein Frontend ohne Fehlerbehandlung bei ihm laufen lassen. Ich melde mich dann wieder.