Sporadisch auftretender Fehler mit Projektnummern
Moderator: SYNERPY
-
- Beiträge: 163
- Registriert: Di Okt 07, 2008 7:54 am
- Wohnort: Oxbüll / Wees
Sporadisch auftretender Fehler mit Projektnummern
Hallo zusammen,
arbeite grade liegengebliebene Fehlermeldungen auf...
Bei uns tritt sporadisch der Fehler:
Beispiel:
ISC ERROR CODE: 335544345
ISC ERROR MESSAGE: lock conflict on no wait transaction
violation of FOREIGNKEY constraint "FK_BLRC_BPROJPO" on table "BLRC"
Diese Fehlermeldung bekommen wir in Einkauf wie Verkauf in allen Masken.
Wie gesagt es tritt sporadisch auf und ich kann keine Regelmäßigkeit feststellen.
- Es ist kein 2. User im selben Moment an dem gleichen Datensatz.
- Es wird nicht zeitgleich ein anderer Datensatz in der selben Maske angelegt.
- Wenn alle aus AvERP herausgehen funktioniert es sofort, kann aber auch nach kurzer Zeit wieder funktionieren, wenn der User sich kurz ausloggt.
Ich vermute es wird etwas mit der Abarbeitung des Servers zu tun haben.
Wo könnte ich noch suchen?
Wäre über Hilfe recht dankbar, da dieses Problem den reibungslosen Ablauf desöfteren schon behindert hat.
Vielen Dank schonmal im Voraus
arbeite grade liegengebliebene Fehlermeldungen auf...
Bei uns tritt sporadisch der Fehler:
Beispiel:
ISC ERROR CODE: 335544345
ISC ERROR MESSAGE: lock conflict on no wait transaction
violation of FOREIGNKEY constraint "FK_BLRC_BPROJPO" on table "BLRC"
Diese Fehlermeldung bekommen wir in Einkauf wie Verkauf in allen Masken.
Wie gesagt es tritt sporadisch auf und ich kann keine Regelmäßigkeit feststellen.
- Es ist kein 2. User im selben Moment an dem gleichen Datensatz.
- Es wird nicht zeitgleich ein anderer Datensatz in der selben Maske angelegt.
- Wenn alle aus AvERP herausgehen funktioniert es sofort, kann aber auch nach kurzer Zeit wieder funktionieren, wenn der User sich kurz ausloggt.
Ich vermute es wird etwas mit der Abarbeitung des Servers zu tun haben.
Wo könnte ich noch suchen?
Wäre über Hilfe recht dankbar, da dieses Problem den reibungslosen Ablauf desöfteren schon behindert hat.
Vielen Dank schonmal im Voraus
Gruß
KTS
AvERP-Exe: 4.2.1.6
Datenbank: AvERP2009-A.01
_________________________
Suchen heißt finden und je mehr man sucht um so mehr findet man.
KTS
AvERP-Exe: 4.2.1.6
Datenbank: AvERP2009-A.01
_________________________
Suchen heißt finden und je mehr man sucht um so mehr findet man.
-
- Beiträge: 38
- Registriert: Fr Dez 26, 2008 11:29 pm
- Wohnort: Langensendelbach
gleicher Effekt
Hallo
diesen, genau diesen Fehler hatten wir heute auch einmal.
in der Maske Wareneingang , es waren bereits ale Daten eingegeben
(auch Pojekt und eine Projektposition 080 (bei uns für 'Bestellvorgänge' genutzt)
die Meldung kam dann ('vorführbar' durch den Bediener) bei der 'Speichern Abfrage' als wir in das Unterprogramm Postionen springen wollten.
Behebung (Zufalls entdeckung) war wir folgt: ich habe bei der Projektpostion einfach 085 ausgewählt (das wäre nach unserer Definition auhc richtiger gewesen, weil diese bei uns Wareneingang heißt)
und schon ging es zu unserer Verblüffung...
diesen, genau diesen Fehler hatten wir heute auch einmal.
in der Maske Wareneingang , es waren bereits ale Daten eingegeben
(auch Pojekt und eine Projektposition 080 (bei uns für 'Bestellvorgänge' genutzt)
die Meldung kam dann ('vorführbar' durch den Bediener) bei der 'Speichern Abfrage' als wir in das Unterprogramm Postionen springen wollten.
Behebung (Zufalls entdeckung) war wir folgt: ich habe bei der Projektpostion einfach 085 ausgewählt (das wäre nach unserer Definition auhc richtiger gewesen, weil diese bei uns Wareneingang heißt)
und schon ging es zu unserer Verblüffung...
mit freundlichen Grüßen
Martin H.
.... seit 2009 in sukzessiver Einführung AVERP .....
nächstes Thema: Chargenverwaltung im Sinne des Materialnachweises nach EN10204 3.1
z.B. für die Druckbehälterverordnung 97/23/EC
nebenbei Zeiterfassung....
Martin H.
.... seit 2009 in sukzessiver Einführung AVERP .....
nächstes Thema: Chargenverwaltung im Sinne des Materialnachweises nach EN10204 3.1
z.B. für die Druckbehälterverordnung 97/23/EC
nebenbei Zeiterfassung....
-
- Beiträge: 163
- Registriert: Di Okt 07, 2008 7:54 am
- Wohnort: Oxbüll / Wees
Bei uns wird die Projektposition eigentlich überhaupt nicht benutzt, sie ist nur da, weil das System es verlangt.
Eine Projektposition wird bei Anlage eines Projektes automatisch erzeugt und danach nicht weiter beachtet.
Nutze ich keine Projektnummer oder eine andere als die vorm Speichern eingegebene kann ich speichern,
ich kann nur nicht die Richtige für oben beschriebene Zeit speichern.
Aber eine Projektnummer ist in unseren Belegen Pflicht...
Wie gesagt wäre über Hilfe sehr dankbar!
Eine Projektposition wird bei Anlage eines Projektes automatisch erzeugt und danach nicht weiter beachtet.
Nutze ich keine Projektnummer oder eine andere als die vorm Speichern eingegebene kann ich speichern,
ich kann nur nicht die Richtige für oben beschriebene Zeit speichern.
Aber eine Projektnummer ist in unseren Belegen Pflicht...
Wie gesagt wäre über Hilfe sehr dankbar!
Gruß
KTS
AvERP-Exe: 4.2.1.6
Datenbank: AvERP2009-A.01
_________________________
Suchen heißt finden und je mehr man sucht um so mehr findet man.
KTS
AvERP-Exe: 4.2.1.6
Datenbank: AvERP2009-A.01
_________________________
Suchen heißt finden und je mehr man sucht um so mehr findet man.
-
- Site Admin
- Beiträge: 2673
- Registriert: Di Feb 10, 2004 5:48 am
- Wohnort: Bayreuth
Das Problem ist uns so nicht bekannt.
Die Art des Fehlers tritt auf, wenn zwei Leute zum selben Zeitpunkt den selben Datensatz aktualisieren wollen. Das muss nicht der Datensatz in derselben Maske sein. Beispiel: Mitarbeiter 1 setzt einen Fertigungsauftrag mit 200 Positionen vom Status P in den Status A. Dadurch springt die Lagerplanung für alle 200 Positionen plus die des Artikels im Fertigungsauftrag an. Mitarbeiter 2 will einen Kundenlieferschein auf gedruckt setzen, der den selben Artikel beinhaltet. Dadurch würde der Lagerbestand aktualisiert werden. Einer der beiden Benutzer bekommt den Fehler, könnte diesen aber wegklicken und danach die Aktion erneut ausführen.
Dass der Fehler bestehen bleibt, ist sehr seltsam. Das würde eigentlich bedeuten, dass ein Anwender den Datensatz über einen längeren Zeitraum hinweg kostant ändert. Das kommt eigentlich nicht vor, da keine Aktion lange dauert, schon gar nicht in Bezug auf Projekte.
Um den Fehler aber dennoch zu beheben, könnten Trigger deaktiviert werden, die beispielsweise die Einkaufskosten in den Projekten aktualisieren. Dadurch würde kein Update erfolgen und auch kein Deadlock erfolgen.
Die Art des Fehlers tritt auf, wenn zwei Leute zum selben Zeitpunkt den selben Datensatz aktualisieren wollen. Das muss nicht der Datensatz in derselben Maske sein. Beispiel: Mitarbeiter 1 setzt einen Fertigungsauftrag mit 200 Positionen vom Status P in den Status A. Dadurch springt die Lagerplanung für alle 200 Positionen plus die des Artikels im Fertigungsauftrag an. Mitarbeiter 2 will einen Kundenlieferschein auf gedruckt setzen, der den selben Artikel beinhaltet. Dadurch würde der Lagerbestand aktualisiert werden. Einer der beiden Benutzer bekommt den Fehler, könnte diesen aber wegklicken und danach die Aktion erneut ausführen.
Dass der Fehler bestehen bleibt, ist sehr seltsam. Das würde eigentlich bedeuten, dass ein Anwender den Datensatz über einen längeren Zeitraum hinweg kostant ändert. Das kommt eigentlich nicht vor, da keine Aktion lange dauert, schon gar nicht in Bezug auf Projekte.
Um den Fehler aber dennoch zu beheben, könnten Trigger deaktiviert werden, die beispielsweise die Einkaufskosten in den Projekten aktualisieren. Dadurch würde kein Update erfolgen und auch kein Deadlock erfolgen.
-
- Beiträge: 399
- Registriert: Fr Mai 26, 2006 3:44 pm
- Wohnort: Velbert-Langenberg
Ja wenn das Problem bei SYNERPY nicht bekannt ist werde ich noch mal einen draufsetzen.admin hat geschrieben:Das Problem ist uns so nicht bekannt.
...
Um den Fehler aber dennoch zu beheben, könnten Trigger deaktiviert werden, die beispielsweise die Einkaufskosten in den Projekten aktualisieren. Dadurch würde kein Update erfolgen und auch kein Deadlock erfolgen.
Mit 2 bis 3 Anwendern im Einkauf und 2 bis 3 im Verkauf, tritt auf einer AvERP-2009-A01 + alle bekannten Update-Scripte durchschnittlich einmal pro Woche
lock conflict on no wait transaction
gegen FK_BBES_BPROJPO on table 'BBES'
auf.
Welche Trigger können deaktiviert werden und welche Folgen hat das,
denn es werden wohl keine Trgigger programmiert, die dann einfach deaktiviert werden können.
Gruß U.Schmidt
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
-
- Beiträge: 399
- Registriert: Fr Mai 26, 2006 3:44 pm
- Wohnort: Velbert-Langenberg
Auch dazu muß ich noch einen Kommentar loslassen, zumal ich mich heute einen ganzen Nachmittag damit beschäftigt habe, die Ursache für eine sehr lange dauernde Transaktion zu finden.admin hat geschrieben:Das Problem ist uns so nicht bekannt.
Dass der Fehler bestehen bleibt, ist sehr seltsam. Das würde eigentlich bedeuten, dass ein Anwender den Datensatz über einen längeren Zeitraum hinweg kostant ändert. Das kommt eigentlich nicht vor, da keine Aktion lange dauert, schon gar nicht in Bezug auf Projekte.
Datenbank AvERP2009-A07
Preisänderung Einkauf
nachvollzogen im IB-Expert über
UPDATE BSAL SET LISTPREIS=LISTPREIS+0.01 WHERE ID=:meine_ID;
dauert 1 Stunde und 47 Minuten
wegen
525.584.638 Non Indexed Reads auf BSAPM
und
525.676.179 Indexed Reads aus BSASTL
beim Aufruf der Prozedure P_BSAS_IN_BSAP
BSAPM hat knapp 100.000 Sätze und das betreffende Material wird in ca. 5400 Stüli-Positionen verwendet - da sind ziemlich genau die 525 Mio Zugriffe beieinander.
Weitere Details sind per direkter Mail an einen SYNERPY-Programmierer gegangen.
Gruß U.Schmidt
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
averpen4dummies.blogspot.de -- off
Wenn ich weiß, wo ich suchen muß ist OpenSource besser als jede Dokumentation
aktuelle Erkenntnisse mit:
Software-Version 6.11.1
FDB 2023.02 / ohne 2024
-
- Beiträge: 163
- Registriert: Di Okt 07, 2008 7:54 am
- Wohnort: Oxbüll / Wees
@admin:
Das Problem taucht nicht nur im Einkauf sondern eben auch im Verkauf auf und zwar in dem Moment, wenn man den Datensatz speichern will.
Versucht man mit einer anderen Projektnummer oder keiner (sofern nicht verlangt) zu speichern funktioniert es.
Versucht man dann über "Bearbeiten" die richtige Projektnummer nachzutragen kommt wieder die Fehlermeldung.
Ich vermute es könnte an der Abarbeitung beim Server liegen. Sobald sich alle einmal ausgelogt haben, bekomme ich die Fehlermeldung nicht mehr beim Eingeben.
Ich kann auch nach Fehlermeldung einen neuen Datensatz anlegen ohne neu einzuloggen oder Fehlermeldung.
Ich tappe leider vollkommen im Dunkeln, da ich diesen Fehler überhaupt nicht reproduzieren kann und damit auch keinen Anhaltspunkt habe,
ausser das es mit der Projektverwaltung zu tun haben muss.
Das Problem taucht nicht nur im Einkauf sondern eben auch im Verkauf auf und zwar in dem Moment, wenn man den Datensatz speichern will.
Versucht man mit einer anderen Projektnummer oder keiner (sofern nicht verlangt) zu speichern funktioniert es.
Versucht man dann über "Bearbeiten" die richtige Projektnummer nachzutragen kommt wieder die Fehlermeldung.
Ich vermute es könnte an der Abarbeitung beim Server liegen. Sobald sich alle einmal ausgelogt haben, bekomme ich die Fehlermeldung nicht mehr beim Eingeben.
Ich kann auch nach Fehlermeldung einen neuen Datensatz anlegen ohne neu einzuloggen oder Fehlermeldung.
Ich tappe leider vollkommen im Dunkeln, da ich diesen Fehler überhaupt nicht reproduzieren kann und damit auch keinen Anhaltspunkt habe,
ausser das es mit der Projektverwaltung zu tun haben muss.
Gruß
KTS
AvERP-Exe: 4.2.1.6
Datenbank: AvERP2009-A.01
_________________________
Suchen heißt finden und je mehr man sucht um so mehr findet man.
KTS
AvERP-Exe: 4.2.1.6
Datenbank: AvERP2009-A.01
_________________________
Suchen heißt finden und je mehr man sucht um so mehr findet man.
-
- Beiträge: 163
- Registriert: Di Okt 07, 2008 7:54 am
- Wohnort: Oxbüll / Wees