Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SE14 Database table check misses obvious inconsistencies

pokrakam
Active Contributor

Background: We experienced some SQL error dumps after deleting fields from a table. We used the SE14 Check runtime and database object functions -> no errors found. I did an adjust just to be sure, but still the dumps continued.

<skip long hunting for other errors part>

Back to basics, we went back in via SE14 and compared the runtime object and database object fields manually one by one, and lo and behold fields were deleted as the database level, but somehow the DDIC structure was still the original.

So my question: What does SE14's "Check" actually do?

According to the help:

  • Check consistency:

    You can compare the table definition in the database with the runtime object of the table by choosing Extras → Database object → Check. The indexes on the table in the ABAP Dictionary are compared with the indexes on the database. You can compare the runtime object of the table with the information entered in the ABAP Dictionary maintenance screen with Extras → Runtime object → Check. Both definitions are displayed. The differences found are highlighted. In both cases you can switch between a delta (only differences) or full (all information) display of the check results.

It definitely didn't do as advertised. Anyone else had this experience?

Running 7.50 on HANA

8 REPLIES 8

kiran_k8
Active Contributor
0 Kudos

Mike,

If these kind of issues persists,I get in touch with the Basis team to make sure if the latest changes in the table are getting reflected at the DB level or not. I faced these kind of issues sometimes while doing APPEND structure in a standard table.

Not sure if there is anything wrong with SE14.

K.Kiran.

pokrakam
Active Contributor

The issue is not so much the data - we understand that part and have fixed it using SE14.

My annoyance is that SE14 was the first thing I checked and it did not report any issues. It gave us the green light and we went on a wild goose chase for a good few hours.

I suppose this is not so much a question as a rant 🙂

matt
Active Contributor

maybe convert to a blog!

kiran_k8
Active Contributor
0 Kudos

https://help.sap.com/saphelp_nw70/helpdata/en/cf/21f0e3446011d189700000e8322d00/frameset.htm

"Normally you should not adjust the database structure during production. At least all the applications that access the table should be deactivated during the structural adjustment. Since the table data is not consistent during the structural adjustment (in particular during conversion), programs could behave incorrectly when they access this data."

"all the applications that access the table should be deactivated" - Is it possible ?

K.Kiran.

pokrakam
Active Contributor

I thought about it but then in my head it was just a simple question - If a consistency check doesn't find existing inconsistencies, what does it do?

But you've got a good point, when I've got a quiet moment I'll move it to a blog.

ImtiazKaredia
Active Contributor
0 Kudos

Did you change tables directly at database level? I mean were the fields dropped using SE11/SE80?

pokrakam
Active Contributor
0 Kudos

Maintained the usual way with SE11, but the underlying issue involved include structures.

What SE11 did was change the order of fields of the runtime object - to me this is a bug.

The adjust deleted the fields but kept the original order in the DB. This caused an SQL error due to mismatch with the runtime version. Easily fixed with SE14 ... but not detected by SE14.

So the table looked line this (simplified):

Include1: 
F1
F2  <--- Deleted
F3
Include 2: 
F4
F5

Resulting runtime object:
F1
F4
F5
F3  <--- The delete "re-appended" the remaining fields at the end

Resulting Database table (correct):
F1
F3
F4
F5