gelöst fehlerhafte Datenbanktabelle


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

gelöst fehlerhafte Datenbanktabelle

Beitragvon abuma » 09.02.2018, 16:26

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: fehlerhafte Datenbanktabelle

Beitragvon Daniel » 09.02.2018, 16:39

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.
Daniel
Specialist
 
Beiträge: 276
Registriert: 10.09.2003, 13:20
Wohnort: Bielefeld
Dank erhalten: 27 mal

Re: fehlerhafte Datenbanktabelle

Beitragvon abuma » 09.02.2018, 16:43

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon deejey » 11.02.2018, 02:41

SE11 liefert sorted by primary key
deejey
ForumUser
 
Beiträge: 28
Registriert: 31.07.2016, 11:20
Dank erhalten: 4 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon abuma » 12.02.2018, 09:03

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon ewx » 12.02.2018, 10:02

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.
ewx
Top Expert
 
Beiträge: 3600
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 258 mal

Re: fehlerhafte Datenbanktabelle

Beitragvon abuma » 12.02.2018, 10:43

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon DeathAndPain » 12.02.2018, 12:02

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.

Für diese Nachricht hat DeathAndPain einen Dank bekommen :
abuma
DeathAndPain
Expert
 
Beiträge: 546
Registriert: 05.05.2006, 10:14
Dank erhalten: 134 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon abuma » 12.02.2018, 12:10

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon ewx » 12.02.2018, 12:55

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.

Für diese Nachricht hat ewx einen Dank bekommen :
abuma
ewx
Top Expert
 
Beiträge: 3600
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 258 mal

Re: fehlerhafte Datenbanktabelle

Beitragvon DeathAndPain » 12.02.2018, 13:25

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?
DeathAndPain
Expert
 
Beiträge: 546
Registriert: 05.05.2006, 10:14
Dank erhalten: 134 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon abuma » 12.02.2018, 15:34

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon DeathAndPain » 13.02.2018, 11:41

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.
DeathAndPain
Expert
 
Beiträge: 546
Registriert: 05.05.2006, 10:14
Dank erhalten: 134 mal
Ich bin: Entwickler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon black_adept » 13.02.2018, 11:50

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
black_adept
Top Expert
 
Beiträge: 2922
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 477 mal
Ich bin: Freiberufler/in

Re: fehlerhafte Datenbanktabelle

Beitragvon abuma » 13.02.2018, 13:07

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
abuma
ForumUser
 
Beiträge: 80
Registriert: 17.08.2016, 11:14
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Nächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Lieferantenkonsignation
vor 9 Minuten von SAP_ENTWICKLER 0 Antw.
Reuse ALV makieren
vor 17 Stunden von a-dead-trousers 1 Antw.
Tabelle TSL1D
vor 17 Stunden von JohnLocklay 0 Antw.
Replace Regex
vor 56 Minuten von black_adept 4 Antw.
Einer dynamisch ermittelten Tabelle Werte zuweisen
vor 18 Stunden von a-dead-trousers 1 Antw.

  Ähnliche Beiträge beta
gelöst ALV Grid OO fehlerhafte Filterung
03.03.2014, 14:12 von erich86 4 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder