Sporadisch auftretender Fehler mit Projektnummern

[NPLADMIN]

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

[martin.h]

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...

[NPLADMIN]

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!

[admin]

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.

[UliS]

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.

Ja wenn das Problem bei SYNERPY nicht bekannt ist werde ich noch mal einen draufsetzen.

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.

[UliS]

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.

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.
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.

[NPLADMIN]

@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.

[admin]

Dauert das Speichern (wenn es denn klappt) lange?

[NPLADMIN]

Nein! Speichergeschwindigkeit ist normal, wenn ich eine andere oder keine Projektnummer nehme.