Unglaublich aber Wahr

[cbe]

@cbe ...

danke nochmal für deine genauere ausführung aber das hatte ich schon gechecked .... .. mein post sollte eigentlich nur ein hinweis sein das punkt drei in einer zweite sitzung gemacht wird....

aber ..... uPPPPSSSS sorry das sind frage zeichen.. bin auch schon blöd.... sorry dast deswegen soviel tippseln hast müssen

kein Problem.


Dass man mit solchen Problemen immer soviel unnütze Zeit verbraten muss, was?


Dass es heute funktioniert ist unfair, wie soll man so den Fehler nachstellen? Ich drück Dir also die Daumen, dass es bald wieder auftritt

Gruß, Christian

[BenderD]

... woraus zweierlei folgen könnte
- stimmt nur, wenn ein kundenstammsatz gefunden wurde und das entsprechende Key Feld nicht überschrieben wurde
- der chain klappt tatsächlich und der Fehler entsteht woanders

D*B

der chain müsste immer klappen weil..

ich verwende das feld länderkennzeichen aus dem kundenstammsatz und mache dann einen chain auf die länderdatei selber und lese einen wert aus....

falsche werte können im länderkennzeichen nicht drin stehen weil ersten wird bei der erfassung gegen tabelle geprüft und zweitens habe ich schon die länderkennzeichen im kundenstamm kontrolliert ob die vom wert her passen und die passen alle...

[woodstock99]

@bender

jupp
aber die routine wird nur duch laufen wenn ein kundenstammsatz da ist ( alles andere wär ja ein grober patzer der programmierung ) und das länderkennzeichen wird nicht überschrieben..

ja variante 2( der chain klappt tatsächlich und der Fehler entsteht woanders) da geb ich dir recht muß auch sein....... nur wo und WARUM ist ja eigentlich die schlüsselfrage...

..
ich lese zuerst rechnungen komplett durch danach danach gutschriften und erzeuge in der buchhaltung offene posten

diese beiden abläufe verwenden die selben routinen im pgm ....

der fehler tritt aber nur ( manchmal je nach tageslaune ) bei den gutschriften auf obwohl es haar genau der gleiche ablauf ist wie bei den rechnungen..

also kopfsatz lesen,

dann positionen verarbeiten,

dann KUNDE lesen anhand des wertes aus dem kopfsatz (Fehlerprüfung usw alles vorhanden, aber kunde muß ja da sein)

so und dann geht die sache mit dem länderkennzeichen los ... (...
wenn dann sind aber immer alle sätze der gutschriften falsch die ich übernehme.....

sprich es wird niergends das länderkennzeichen verarbeitet aber wie gesagt auch wiederrum nur TAGESFORM weiße....

hab jetzt das programm 345634836 mal gedebugged ) und es hat immer gefunzt weil die werte einfach da sein müssen ......

[woodstock99]

@cbe.....

merci fürs daumen drücken )).. ich geb die hoffnung nicht auf ))

[BenderD]

... wobei wir wieder beim OVRDBF als Hauptkandidat sind; da muss es irgendwo einen Unterschied im Callstack geben, oder in der Ablaufhistorie des Programms...

D*B
, der schon weiß warum sich seine Nackenhaare beim OVRDBF und den LIBL Spielereien kräuseln...

wenn dann sind aber immer alle sätze der gutschriften falsch die ich übernehme.....
......

[woodstock99]

@ bender


ja das hab ich mir auch schon gedacht aber des kann doch nicht sein oder ...


- also ablauf zu 100 % identisch aber sowas von )...


- ovrdbf des muß doch funzen oder hat der befehl ab und zu einen an der waffel ??
ich glaub schön langsam an alles ..


in jedem cl ist es immer der gleiche ablauf bei uns

OVRDBF FILE(xxx) TOFILE(xxx/xxx) +
OVRSCOPE(*JOB) OPNSCOPE(*JOB)
CALL PGM (xxx/xxx)

DLTOVR FILE(*ALL) LVL*JOB)

also alle überscheibungen werden nach beenden des jobs gelöscht....

[BenderD]

... Programmierer haben eine Waffel, ein Command kann wegen fehlender nix an selbiger haben...

OVRDBF können allerdings von der Jobhistorie beeinflusst sein!!!
Wenn ein OVRDBF bestehen bleibt (wg. abnormal exit z.B.), dann zieht ein nachfolgender OVRDBF gleichen Namens ohne SECURE(*YES) nicht mehr!!!
Wenn eine Datei offen bleibt ist ein nachfolgender OVRDBF ohne Effekt (da gabs in der Tat mal in der Kombination mit SQL Zugriffen Betriebssystem Probleme).

D*B

@ bender


ja das hab ich mir auch schon gedacht aber des kann doch nicht sein oder ...


- also ablauf zu 100 % identisch aber sowas von )...


- ovrdbf des muß doch funzen oder hat der befehl ab und zu einen an der waffel ??
ich glaub schön langsam an alles ..


in jedem cl ist es immer der gleiche ablauf bei uns

OVRDBF FILE(xxx) TOFILE(xxx/xxx) +
OVRSCOPE(*JOB) OPNSCOPE(*JOB)
CALL PGM (xxx/xxx)

DLTOVR FILE(*ALL) LVL*JOB)

also alle überscheibungen werden nach beenden des jobs gelöscht....

[Liebhoff]

Also ich bin der Meinung ich hatte genau den selben Murks auch schon mal. Das Problem war damals aber gar nicht der OVR sondern das RPG dort wurde der CHAIN in die Datei gemacht. Die Datei war UPDATE eröffnet wurde aber tatsächlich nur für einen INPUT mit CHAIN genutzt. Ich hatte das selbe Phänomen, mit Debug gings ohne nicht. Habe damals dann erst in einer Dummy Routine (welche nie aufgerufen wurde) einen WRITE und einen UPDATE auf die Datei eingebaut. Das hat dann gefunzt. Da ich natürlich aber sauber arbeiten wollte, habe ich dann am Ende auf eine nur INPUT eröffnete Datei umgestellt. Der Update erfolgte über eine andere logische Datei. Wahrscheinlich eröffnet der Debug Modus die Datei anders, verstanden habe ich es eigentlich nie richtig, nur es lief dann wie gesagt. Auch an dieser Stelle galt eben mal wieder RPG - Raten Probieren Glauben.

Wollte nur mal diesen anderen Aspekt einwerfen, vielleicht hilft es ja.

Thomas

[Robi]

Ich hatte mal was ähnliches ...
daher sag ich mal :
Für mich liest sich das als ob die Datei, warum auch immer, beim OVR schon offen ist.
Wie sind eure ACTGRP Parameter ?
alles *caller oder alles QILE
Gruß
Robi

[woodstock99]

so sorry das es ein wenig gedauert hat aber urlaub/krank usw......

um aber dieses thema abzuschließen wollte ich nur schreiben das ich das programm nochmal komplett neu codiert (in free rpg) habe und jetzt funzt es..

warum es aber jetzt funzt das weiß der himmel......

[andreaspr@aon.at]

hallo *all,
das problem kenne ich!
mit dem debugger bin ich auch schon auf genau solche probleme gestoßen.

habe ein pgm erweitert, und bei mir gings nicht und bei einem kollegen gings. (gleicher user, gleiche libl usw.)
ich war auch total verwirrt, da ich sowas noch nie erlebt habe. habe aber auch selten mit debugger gearbeitet.

jedoch wird in unserer firma oft der debugger eingesetzt und daher ist dieses problem nicht unbekannt.
ich weis zwar nicht wie dieses problem zu lösen ist (wenn überhaupt). was ich aber weis ist, dass der debugger kein perfektes tool ist! zumindest auch bei den nicht-free programmen.

lg andreas

[woodstock99]

@andreaspr@aon.at..

also der debugger ist ja ganz ok und ich hatte auch noch nie probleme damit...

naja der komfort ich gegensatz z.b. zum visual studio debugger hält sich aber echt in grenzen ))...

aber mei so ist sie halt unsere black box )