fehlerhafte Datenbanktabelle
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.huhu,
ich habe folgendes Problem und hoffe mir kann da wer weiter helfen:
bei einer Z-Datenbanktabelle habe ich Selektions- und Anzeigefehler (SE16N) sowie beim SELECT-Befehl.
Key-Felder der Tabelle sind:
In der Tabelle gibt es zu jeder ID 2 Einträge also laufende Nummer (LFDNR) 1 und 2.
Wenn ich mir jetzt in der SE16N alle Einträge anzeigen lasse werden diese korrekt angezeigt.
Objekt1 ID1 LFDNR1
Objekt1 ID1 LFDNR2
Wenn ich jetzt in der SE16N max. 500 Zeilen anzeigen lasse oder im Select UP TO 500 ROWS angebe ohne sonstige Selektionskriterien erhalte ich nur Einträge mit der laufenden Nummer 2:
Objekt1 ID1 LFDNR2
Objekt1 ID2 LFDNR2
Erwartet hätte ich aber eigentlich:
Objekt1 ID1 LFDNR1
Objekt1 ID1 LFDNR2
Objekt1 ID2 LFDNR1
Objekt1 ID2 LFDNR2
Die Sätze zur LFDNR 1 fehlen auf einmal sind aber eigentlich vorhanden.
Ein weiteres Feld der Tabelle (Nichtschlüsselfeld) wäre zB Konto (CHAR 10) wenn ich auf das selektiere erhalte ich nur Einträge zur laufenden Nummer 1... die mit der laufenden Nummer 2 fehlen.
Es gibt noch weitere komische Effekte, die ich gerne noch weiter ausführen kann, falls meine ersten Beschreibungen nicht ausreichen.
Hat jemand denn schon mal solche Fehler gehabt?
Und woran könnte das liegen?
Ich habe in der SE14 auf Fehler geprüft, dort scheint aber alles in Ordnung zu sein.
Bei der Selektion der Daten habe ich z.B. bei dem Fall mit dem Konto auch die Konvertierung berücksichtigt, daran kann es also nicht liegen.
Liebe Grüße und vielen Dank im Voraus
abuma
ich habe folgendes Problem und hoffe mir kann da wer weiter helfen:
bei einer Z-Datenbanktabelle habe ich Selektions- und Anzeigefehler (SE16N) sowie beim SELECT-Befehl.
Key-Felder der Tabelle sind:
Code: Alles auswählen.
Feld | Datentyp | Länge
-------------------------
MANDT | CLNT | 3
OBJECT | CHAR | 4
ID | NUMC | 9
LFDNR | NUMC | 4
Wenn ich mir jetzt in der SE16N alle Einträge anzeigen lasse werden diese korrekt angezeigt.
Objekt1 ID1 LFDNR1
Objekt1 ID1 LFDNR2
Wenn ich jetzt in der SE16N max. 500 Zeilen anzeigen lasse oder im Select UP TO 500 ROWS angebe ohne sonstige Selektionskriterien erhalte ich nur Einträge mit der laufenden Nummer 2:
Objekt1 ID1 LFDNR2
Objekt1 ID2 LFDNR2
Erwartet hätte ich aber eigentlich:
Objekt1 ID1 LFDNR1
Objekt1 ID1 LFDNR2
Objekt1 ID2 LFDNR1
Objekt1 ID2 LFDNR2
Die Sätze zur LFDNR 1 fehlen auf einmal sind aber eigentlich vorhanden.
Ein weiteres Feld der Tabelle (Nichtschlüsselfeld) wäre zB Konto (CHAR 10) wenn ich auf das selektiere erhalte ich nur Einträge zur laufenden Nummer 1... die mit der laufenden Nummer 2 fehlen.
Es gibt noch weitere komische Effekte, die ich gerne noch weiter ausführen kann, falls meine ersten Beschreibungen nicht ausreichen.
Hat jemand denn schon mal solche Fehler gehabt?
Und woran könnte das liegen?
Ich habe in der SE14 auf Fehler geprüft, dort scheint aber alles in Ordnung zu sein.
Bei der Selektion der Daten habe ich z.B. bei dem Fall mit dem Konto auch die Konvertierung berücksichtigt, daran kann es also nicht liegen.
Liebe Grüße und vielen Dank im Voraus
abuma
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Die wenigsten Datenbanken liefern selektierte Sätze sortiert.
Wenn man die Anzahl begrenzt hat man daher u.U. genau die
von die geschilderten Ergebnissen.
In eigenen Programmen hilft die Clause order by Primary key.
Wenn man die Anzahl begrenzt hat man daher u.U. genau die
von die geschilderten Ergebnissen.
In eigenen Programmen hilft die Clause order by Primary key.
Aber es fehlen ja auch Sätze bei der Selektion.
Nochmal das Konto-Beispiel:
Ich mache einen Select auf Feld Konto und ich weiß, dass ich zu diesem Konto 8 Sätze habe 4 mit LFDNR 1 und 4 mit LFDNR 2.
Ich erhalte aber bei meinem Select nur die 4 Sätze mit LFDNR 1.
Das kann doch nicht stimmen?
Liebe Grüße
abuma
Nochmal das Konto-Beispiel:
Ich mache einen Select auf Feld Konto und ich weiß, dass ich zu diesem Konto 8 Sätze habe 4 mit LFDNR 1 und 4 mit LFDNR 2.
Ich erhalte aber bei meinem Select nur die 4 Sätze mit LFDNR 1.
Das kann doch nicht stimmen?
Code: Alles auswählen.
SELECT * FROM zdb_tab
INTO TABLE t_table
WHERE konto = '1234567890'.
abuma
In der SE11 fehlen ebenfalls die genannten Einträge in der Auflistung.
Wir haben inzwischen die Vermutung, dass es daran liegen könnte, dass im Nachhinein nochmals Felder in der Tabelle hinzukamen und dadurch dieser Fehler entsteht.
Sobald die Tabelle komplett geleert werden kann werden wir diese nochmals neu anlegen und dann melde ich mich nochmal, ob der Fehler dadurch behoben werden konnte.
Derzeit befindet sich ja alles noch im Entwicklungsstatus. Auf dem Produktiv wäre das ja schon sehr blöd
Liebe Grüße
abuma
Wir haben inzwischen die Vermutung, dass es daran liegen könnte, dass im Nachhinein nochmals Felder in der Tabelle hinzukamen und dadurch dieser Fehler entsteht.
Sobald die Tabelle komplett geleert werden kann werden wir diese nochmals neu anlegen und dann melde ich mich nochmal, ob der Fehler dadurch behoben werden konnte.
Derzeit befindet sich ja alles noch im Entwicklungsstatus. Auf dem Produktiv wäre das ja schon sehr blöd
Liebe Grüße
abuma
Du bist sicher, dass genau diese Kontonummer exakt gleich auf der Datenbank für die LFNDR vorhanden sind?abuma hat geschrieben:Aber es fehlen ja auch Sätze bei der Selektion.
Nochmal das Konto-Beispiel:
Ich mache einen Select auf Feld Konto und ich weiß, dass ich zu diesem Konto 8 Sätze habe 4 mit LFDNR 1 und 4 mit LFDNR 2.
Ich erhalte aber bei meinem Select nur die 4 Sätze mit LFDNR 1.
Das kann doch nicht stimmen?
Liebe GrüßeCode: Alles auswählen.
SELECT * FROM zdb_tab INTO TABLE t_table WHERE konto = '1234567890'.
abuma
Gerade bei Nummern, die als CHAR-Feld gespeichert werden, kann es dazu kommen, dass du z.B. 12345 eingibst, 12345 siehst, tatsächlich aber 0000012345 gespeichert wurde.
Um das zu prüfen, bitte mal in der SE16 alle Datensätze selektieren und mit Doppelklick die Datensätze vergleichen (Beim Doppelklick öffnet sich ein Fenster, in dem der angezeigte Wert als auch der "echte" Wert dargestellt werden.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Sowas hätte ich noch nie erlebt. Die SE11/SE14 ist da sehr pfiffig und verwirft bei mir eigentlich nie Daten, die sie retten könnte, auch wenn ic hwild Spalten lösche oder hinzufüge. Ich könnte es mir nur dann vorstellen, wenn zwischenzeitlich das Feld LFDNR in der SE11 nicht als Schlüsselfeld markiert gewesen wäre. Dann hätte die Datenbank beim Aktivieren keine andere Wahl gehabt, als die Hälfte der Einträge zu verwerfen, und wenn man den Schlüsselfeldhaken später wieder hinzufügt, dann bleiben die Zeilen natürlich trotzdem weg.abuma hat geschrieben:Wir haben inzwischen die Vermutung, dass es daran liegen könnte, dass im Nachhinein nochmals Felder in der Tabelle hinzukamen und dadurch dieser Fehler entsteht.
Genau andersrum. Die (alte) SE16 stellt die Felder in der Übersichtsliste richtig dar, beim Doppelklick auf eine Zeile laufen die Werte dann aber durch den CONVERSION_EXIT.ewx hat geschrieben:Gerade bei Nummern, die als CHAR-Feld gespeichert werden, kann es dazu kommen, dass du z.B. 12345 eingibst, 12345 siehst, tatsächlich aber 0000012345 gespeichert wurde.
Um das zu prüfen, bitte mal in der SE16 alle Datensätze selektieren und mit Doppelklick die Datensätze vergleichen (Beim Doppelklick öffnet sich ein Fenster, in dem der angezeigte Wert als auch der "echte" Wert dargestellt werden.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
abuma
Also die Daten sind ja trotzdem auf der Datenbank nur werden sie teilweise nicht gefunden.
Wenn ich mir die komplette Tabelle anzeige werden die Einträge die ich im genannten Konto-Fall vermisse auch angezeigt.
Wenn ich aber auf das Konto selektiere oder auf Zeilen begrenze fehlen mir die Zeilen in der Ansicht von SE11 sowie SE16N sowie im SELECT-Ergebnis.
Da ich die Tabelle nicht selbst angelegt habe weiß ich leider nicht wann welche Felder hinzukamen und entfernt wurden bzw. wann Key-Felder gesetzt wurden.
Aber meine Kollegin hatte dieses Problem auch schon bei einer anderen Tabelle. Ihres Wissens nach trat dieser Fehler auf nachdem sie ein neues Feld eingefügt hat.
Ich hatte dieses Problem bis jetzt noch die und kann mir auch die Fehlerursache nicht wirklich erklären.
Liebe Grüße
abuma
Wenn ich mir die komplette Tabelle anzeige werden die Einträge die ich im genannten Konto-Fall vermisse auch angezeigt.
Wenn ich aber auf das Konto selektiere oder auf Zeilen begrenze fehlen mir die Zeilen in der Ansicht von SE11 sowie SE16N sowie im SELECT-Ergebnis.
Da ich die Tabelle nicht selbst angelegt habe weiß ich leider nicht wann welche Felder hinzukamen und entfernt wurden bzw. wann Key-Felder gesetzt wurden.
Aber meine Kollegin hatte dieses Problem auch schon bei einer anderen Tabelle. Ihres Wissens nach trat dieser Fehler auf nachdem sie ein neues Feld eingefügt hat.
Ich hatte dieses Problem bis jetzt noch die und kann mir auch die Fehlerursache nicht wirklich erklären.
Liebe Grüße
abuma
Das Problem kenne ich mit INITIAL-Werten. Da ist es genau so, wie du es beschreibst, nur mit leeren Einträgen.
Wenn du eine Tabelle mit Daten hast und ein Feld hinzufügst und das "Initialisieren-Flag" nicht setzt, dann haben alle vorhandenen Datensätze in dem neuen Feld den Wert "NULL".
Wenn du Werte selektierst mit SELECT ... WHERE neues_feld = space, dann findest du es nicht, weil der Wert eben nicht SPACE ist, sondern <null>. Du müsstest dann direkt auf IS NULL selektieren.
Das kann aber in deinem Fall nicht sein, weil ja Werte vorhanden sind.
Wenn du eine Tabelle mit Daten hast und ein Feld hinzufügst und das "Initialisieren-Flag" nicht setzt, dann haben alle vorhandenen Datensätze in dem neuen Feld den Wert "NULL".
Wenn du Werte selektierst mit SELECT ... WHERE neues_feld = space, dann findest du es nicht, weil der Wert eben nicht SPACE ist, sondern <null>. Du müsstest dann direkt auf IS NULL selektieren.
Das kann aber in deinem Fall nicht sein, weil ja Werte vorhanden sind.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Ich kan auch keine Antwort aus dem Ärmel schütteln, aber es wäre mal interessant, wie genau die Tabelle definiert ist. abuma, kannst Du mal einen Screenshot der SE11 mit den Feldern (zumindest was davon auf den Bildschirm raufpasst) posten?
Auslieferungsklasse A
Die Domäne von Feld KONTO sowie KONTO_ALT ist SAKNR, darin befindet sich die Konvertierungsroutine ALPHA.
In der im Thread genannten DB werden diese Felder ohne führende Nullen abgespeichert.
Ich habe mal eine Testtabelle nachgebaut, Schlüssel wie bei der aus dem Screenshot und Feld KONTO mit Datenelement SAKNR.
Wenn ich einen Eintrag mit Konto ohne führende Nullen abspeichere, erhalte ich in der SE16N kein Ergebnis wenn ich das Konto ohne führende Nullen eingebe, da dort nochmals Konvertiert wird und dadurch der Eintrag nicht gefunden werden kann.
Klingt für mich auch logisch und so wie ihr es ja auch beschrieben habt.
Allerdings verhält es sich ja in meiner eigentlichen fehlerhaften Tabelle nicht so!?
Ich finde ja die Kontoeinträge, aber eben nur mit LFDNR 1.
Also meiner Meinung nach müsste man die Felder die die Konvertierungsroutine haben auch mit führenden Nullen in der DB speichern, oder eben eine Domäne ohne Konv.routine angeben.
Aber ich glaube in der DB-Tabelle passt dennoch was nicht, wegen der LFDNR.
Ich warte jetzt mal ab bis die ersten Tests vorbei sind und passe dann die Felder mit ALPHA-Konv. an und lege die Tabelle ggf. mal neu an…
Und dann melde ich mich nochmal.
Liebe Grüße
abuma
Die Domäne von Feld KONTO sowie KONTO_ALT ist SAKNR, darin befindet sich die Konvertierungsroutine ALPHA.
In der im Thread genannten DB werden diese Felder ohne führende Nullen abgespeichert.
Ich habe mal eine Testtabelle nachgebaut, Schlüssel wie bei der aus dem Screenshot und Feld KONTO mit Datenelement SAKNR.
Wenn ich einen Eintrag mit Konto ohne führende Nullen abspeichere, erhalte ich in der SE16N kein Ergebnis wenn ich das Konto ohne führende Nullen eingebe, da dort nochmals Konvertiert wird und dadurch der Eintrag nicht gefunden werden kann.
Klingt für mich auch logisch und so wie ihr es ja auch beschrieben habt.
Allerdings verhält es sich ja in meiner eigentlichen fehlerhaften Tabelle nicht so!?
Ich finde ja die Kontoeinträge, aber eben nur mit LFDNR 1.
Also meiner Meinung nach müsste man die Felder die die Konvertierungsroutine haben auch mit führenden Nullen in der DB speichern, oder eben eine Domäne ohne Konv.routine angeben.
Aber ich glaube in der DB-Tabelle passt dennoch was nicht, wegen der LFDNR.
Ich warte jetzt mal ab bis die ersten Tests vorbei sind und passe dann die Felder mit ALPHA-Konv. an und lege die Tabelle ggf. mal neu an…
Und dann melde ich mich nochmal.
Liebe Grüße
abuma
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Weil die SE16N die Konvertierungsroutine aufruft und mit führenden Nullen sucht. Auf der Datenbank sollte es also auch nur Werte mit führenden Nullen geben. Auch wenn ich nicht weiß, wie es in Deinem Fall dazu kommen könnte: Achte darauf, dass Deine Kontonummer vollständig rechtsbündig ist, bevor Du sie links mit Nullen auffüllst und auf die Datenbank schreibst. Auf der sicheren Seite bist Du, wenn Du bei Deiner Kontonummer die folgenden Befehle ausführst:Wenn ich einen Eintrag mit Konto ohne führende Nullen abspeichere, erhalte ich in der SE16N kein Ergebnis wenn ich das Konto ohne führende Nullen eingebe, da dort nochmals Konvertiert wird und dadurch der Eintrag nicht gefunden werden kann.
Code: Alles auswählen.
SHIFT konto RIGHT DELETING TRAILING SPACE.
OVERLAY konto WITH '0000000000'.Ja, das ist schon extrem seltsam. Frage aus Neugier: Was für eine Datenbank setzt ihr ein?Allerdings verhält es sich ja in meiner eigentlichen fehlerhaften Tabelle nicht so!?
Ich finde ja die Kontoeinträge, aber eben nur mit LFDNR 1.
Das ist aber eigentlich ein Fehler. Das Datenelement ist mit dem Conversion Exit definiert, also müssen die auf der Datenbank abgelegten Werte sich auch an das interne Format dieses Conversion Exits halten. Entweder ihr macht das so (z.B. unter Nutzung der o.g. Befehle oder indem ihr selber den Conversion Exit aufruft), oder ihr nehmt eine andere Domäne dafür, die keinen Conversion Exit hat. Ansonsten kann ich mir schon vorstellen, dass die internen Abläufe in SAP wegen dieses Konsistenzfehlers zu undefinierten Ergebnissen kommen.In der im Thread genannten DB werden diese Felder ohne führende Nullen abgespeichert.
Natürlich kann es auch sein, dass in der Datenbank irgendwas schief ist, aber so richtig vorstellen kann ich es mir kaum, dazu habe ich SE11 und SE14 als zu zuverlässig kennengelernt. Bevor ich in der Richtung suche, würde ich an Deiner Stelle erst mal den o.g. formalen Fehler glattziehen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Kann man machen - sollte es aber nicht. Wenn du schon weißt, dass es einen Konvertierungsexit gibt ( hier ALPHA ) dann rufe doch den zugehörigen Exit auf ( hier CONVERSION_EXIT_ALPHA_INPUT ). Das ist i.A. sicherer und in diesem Fall auch schneller.DeathAndPain hat geschrieben: Auf der sicheren Seite bist Du, wenn Du bei Deiner Kontonummer die folgenden Befehle ausführst:
Code: Alles auswählen.
SHIFT konto RIGHT DELETING TRAILING SPACE. OVERLAY konto WITH '0000000000'.
HDBDeathAndPain hat geschrieben:Ja, das ist schon extrem seltsam. Frage aus Neugier: Was für eine Datenbank setzt ihr ein?
Also wenn dann würde ich den CONVERSION_EXIT_ALPHA_INPUT aufrufen.
Derzeit kann ich noch keine Änderungen vornehmen, aber ich melde mich dann nochmal.
Liebe Grüße
abuma
Vergleichbare Themen
4
Antw.
Antw.
2640
Views
Views
2
Antw.
Antw.
7438
Views
Views
analog COGI: Fehlerhafte Warenbewegungen im Hintergrund
von hsiebert » 05.09.2007 11:31 • Verfasst in Material Management & Produktionsplanung
von hsiebert » 05.09.2007 11:31 • Verfasst in Material Management & Produktionsplanung
1
Antw.
Antw.
594
Views
Views
Fehlerhafte FAX-Sendungen (SCOT) erneut anstoßen - Job
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
1725
Views
Views
fehlerhafte Ausgabe einer internen Tabelle im Popup
von Alexander D. » 13.03.2007 12:11 • Verfasst in ABAP® Core
von Alexander D. » 13.03.2007 12:11 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1073
vor 2 Tagen von DeathAndPain 4 / 1073
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1073
vor 2 Tagen von DeathAndPain 4 / 1073