fehlerhafte Datenbanktabelle

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
48 Beiträge • Seite 1 von 4 (current) Nächste
48 Beiträge Seite 1 von 4 (current) Nächste

fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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:

Code: Alles auswählen.

Feld   | Datentyp | Länge
-------------------------
MANDT  | CLNT     | 3
OBJECT | CHAR     | 4
ID     | NUMC     | 9
LFDNR  | NUMC     | 4
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: fehlerhafte Datenbanktabelle

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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?

Code: Alles auswählen.

SELECT * FROM zdb_tab
   INTO TABLE t_table
   WHERE konto = '1234567890'.
Liebe Grüße
abuma

Re: fehlerhafte Datenbanktabelle

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
SE11 liefert sorted by primary key

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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?

Code: Alles auswählen.

SELECT * FROM zdb_tab
   INTO TABLE t_table
   WHERE konto = '1234567890'.
Liebe Grüße
abuma
Du bist sicher, dass genau diese Kontonummer exakt gleich auf der Datenbank für die LFNDR vorhanden sind?
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.

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
Ja, da habe ich darauf geachtet und es auch eben zur Sicherheit nochmals angesehen.
Habe die Tabelle auch mit anderen Tabellen verglichen und konnte da nichts auffälliges feststellen.

Liebe Grüße
abuma

Re: fehlerhafte Datenbanktabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.
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.
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.
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.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
abuma


Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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

Re: fehlerhafte Datenbanktabelle

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
abuma


Re: fehlerhafte Datenbanktabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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?

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
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

Re: fehlerhafte Datenbanktabelle

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.
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:

Code: Alles auswählen.

SHIFT konto RIGHT DELETING TRAILING SPACE.
OVERLAY konto WITH '0000000000'.
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.
Ja, das ist schon extrem seltsam. Frage aus Neugier: Was für eine Datenbank setzt ihr ein?
In der im Thread genannten DB werden diese Felder ohne führende Nullen abgespeichert.
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.

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.

Re: fehlerhafte Datenbanktabelle

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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'.
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: fehlerhafte Datenbanktabelle

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
DeathAndPain hat geschrieben:Ja, das ist schon extrem seltsam. Frage aus Neugier: Was für eine Datenbank setzt ihr ein?
HDB

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.
2213
Views
Fehlerhafte XML-Datei
von einar46 » 03.09.2014 21:56 • Verfasst in ABAP® Core
4
Antw.
2207
Views
ALV Grid OO fehlerhafte Filterung
von erich86 » 20.02.2014 00:07 • Verfasst in ABAP® für Anfänger
2
Antw.
6967
Views
2
Antw.
3213
Views
fehlerhafte workflows aus business-workplace entfernen?
von Loki » 20.08.2004 12:27 • Verfasst in ABAP Objects®
1
Antw.
473
Views
Fehlerhafte FAX-Sendungen (SCOT) erneut anstoßen - Job
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger

Ü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

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.