How to prevent inconsistencies when modifing the database from a snapshot?

[former_member705295]

Hi, I have to build a program, that works similar to how the SE16N did. Since I am still very inexperienced with ABAP and software development as a whole, I would like to ask for some guidance here, so the program won't mess up the data.

Basically the program should look almost identical to the SE16N and allow the user to insert new entries, delete entries and edit every field in existing entries.

I have 2 problems.

First: Everything is supposed to be editable. I suggested to add new entries through a dialogue, so you never have entries without keys in the itab, but the POs want the grid to be editable. New entries are added as empty rows, so the keys need to be editable too, so they can be set.

Second: The user can view only a fraction of the database with select options. Combined with the fact, that every field is editable, this produces the problem, that I can't modify the database from an itab, without risking inconsistencies. Because some key values might have been changed and might not fit into the select options anymore. So I can't check the edited itab against the fraction anymore. But I can't check against the whole database either. Because there are a lot of entries missing and the program wouldn't know if they were deleted or were never requested in the first place.

I only see two possible solutions right now. One is to disable the select options and show the whole database. Most database tables are rather small and this wouldn't cause a problem. But there are two tables, that are rather large and I know, at least one user actively used the select options in the SE16N and would like to have them in the new program too.

The other is to keep the select options and track every edit in a separate table, that stores database actions. So for example:

insert/keyXYZ/data

delete/keyXXX/data

update/keyXYZ/data

And then I could execute it in the order, it was performed by the user. But this seems extremely error prone. Because if there is a bug in the database actions, the table shown to the user wouldn't match, to what the database would look like if the actions are executed. And it could be rather hard to find bugs here.

So if restricting users or creating an error prone mess are the only options I have, than I would probably rather restrict the users.But maybe someone, who is more experienced with ABAP, than I am, knows another solution.

[former_member705295]

In the end I decided to disable the select options.

If the user wants to filter the data, that is shown in the ALV-Grid he can do so with the filter function of the ALV. So the user can still get the same functionality, he would get from the select options, just in a different spot. But it makes the program much more clean and stable.

The only downside is, that the program will always query the whole database, even if the user only needs a fraction of the data. But since the query is only executed once and most tables are rather small, I think the benefits of having a more stable and maintainable program outweigh the downside.