Lesson 9 Practice — Prove Safe SQL Writes

In Lesson 8 Practice, you created:

ZISSUE_###

Today you will prove that you can manipulate it safely from ABAP.

Create:

ZCL_ISSUE_SQL_###

This is not just a "CRUD checklist."

Your main proof is:

Changing or deleting Issue A must not accidentally affect Issue B.

---

Practice information

Expected time	About 3 hours
Environment	SAP BTP ABAP Trial
Existing table	ZISSUE_###
New class	ZCL_ISSUE_SQL_###
Rows used	Two
Final table state	Cleaned up

---

Part 1 — Verify yesterday's table

Open:

ZISSUE_###

Confirm it is active.

Open Data Preview:

Alt + F8

If the table contains unrelated rows from earlier experiments, do not delete them.

Your class must operate only on UUIDs generated during its own run.

---

Part 2 — Create the class

Create:

ZCL_ISSUE_SQL_###

Implement:

IF_OO_ADT_CLASSRUN

Do not copy the Companion solution before attempting the task.

---

Part 3 — Generate two UUIDs

Create:

uuid_a
uuid_b

Both must use the X16 UUID API from the guided lesson.

Handle the UUID exception.

If UUID generation fails:

output the error
return

---

Part 4 — Create Issue A

Use VALUE zissue_###.

Required values:

IssueNo:        00000001
Title:          Cannot publish service
RequesterEmail: student@example.com
Priority:       H
Status:         O
ReportedOn:     current date
EstimatedCost:  75.00
Currency:       EUR

Do not fill:

client
RAP administrative fields

---

Part 5 — Create Issue B

Use a different UUID.

Suggested values:

IssueNo:        00000002
Title:          Data preview mismatch
RequesterEmail: student@example.com
Priority:       M
Status:         O
ReportedOn:     current date
EstimatedCost:  40.00
Currency:       EUR

---

Part 6 — Insert both rows

Insert Issue A.

Immediately capture:

sy-dbcnt

Insert Issue B.

Immediately capture:

sy-dbcnt

Expected:

A → 1
B → 1

Output both counts.

---

Part 7 — Read both rows back

Read the two UUIDs.

Display at least:

IssueNo
Title
Priority
Status

Prove that two distinct rows exist.

---

Part 8 — Update only Issue A

Change:

Issue A Status
O → I

Use:

uuid_a

in the WHERE condition.

Immediately capture the updated row count.

Expected:

1

---

Part 9 — Prove Issue B was not changed

Read Issue A.

Read Issue B.

Expected:

A Status = I
B Status = O

This is one of the most important outputs in the Practice.

It proves your WHERE condition was selective.

---

Part 10 — Delete only Issue A

Delete:

Issue A

using:

uuid_a

Expected row count:

1

---

Part 11 — Prove Issue B still exists

Read:

uuid_b

after deleting A.

Expected:

Issue B still exists
Status = O

If B disappeared, your delete logic was unsafe.

---

Part 12 — Clean up Issue B

Delete only:

uuid_b

Capture:

sy-dbcnt

Expected:

1

---

Part 13 — Verify final cleanup

Open Data Preview again.

Your two test rows should be gone.

If unrelated rows existed before the exercise, they should still be there.

That distinction matters.

---

Part 14 — Safety audit

Copy the two statements from your class that can be most destructive:

UPDATE ...
DELETE ...

For each, write:

Target condition:
Rows that can be affected:
Why this is safe:

---

Part 15 — Row-count audit

Record the observed values:

Operation	Expected	Actual
Insert A	1
Insert B	1
Update A	1
Delete A	1
Delete B	1

If an actual value differs, explain why before submitting.

---

Part 16 — Client-handling reasoning

Answer:

Why did you not assign the client field?

Why did the WHERE conditions not include client = @sy-mandt?

Does implicit client handling mean every user is authorized to access every row in the client?

---

Part 17 — Admin-field reasoning

After the INSERT, inspect the RAP administrative fields if useful.

Answer:

Why should you not expect today's direct SQL class to behave like a managed RAP runtime?

Mention at least:

administrative fields
behavior rules
transactional abstraction

---

Part 18 — Direct SQL vs future RAP

Complete:

Today:
Consumer → __________ → ZISSUE_###

Later:
Consumer → __________ → RAP BO → ZISSUE_###

Then list at least four things a future RAP BO can protect or coordinate that direct SQL can bypass.

---

Part 19 — Certification-style debugging case

A class runs:

UPDATE zissue_###
  SET status = 'C'
  WHERE uuid = @uuid.

DATA(updated_rows) = sy-dbcnt.

Output:

Updated rows: 0

Give at least three plausible explanations that do not require changing the SQL syntax.

---

Optional challenge — Zero-row test

Generate a third UUID:

uuid_missing

Do not insert it.

Run a targeted update using that UUID.

Expected:

sy-dbcnt = 0

Explain why this is a valid result rather than necessarily an error.

---

Optional challenge — Improve output

Make your console output clearly show the lifecycle:

=== CREATED ===
...
=== AFTER TARGETED UPDATE ===
...
=== AFTER DELETE A ===
...
=== CLEANUP COMPLETE ===

Do not change the persistence logic.

---

Submission checklist

• ZCL_ISSUE_SQL_### exists and activates.
• Two fresh X16 UUIDs are generated.
• UUID exceptions are handled.
• Issue A and Issue B use the table type.
• Insert A processes one row.
• Insert B processes one row.
• Both rows are read back.
• Only Issue A is updated.
• A becomes I.
• B remains O.
• Only Issue A is deleted first.
• Issue B still exists afterward.
• Issue B is cleaned up separately.
• Every UPDATE/DELETE has a UUID-based WHERE condition.
• sy-dbcnt is captured immediately.
• Client-handling questions are answered.
• Direct SQL vs RAP reasoning is completed.
• Final Data Preview contains none of your two test rows.

---

Useful ADT actions

Action	Shortcut
Open object	Ctrl + Shift + A
Content assist	Ctrl + Space
Quick Fix	Ctrl + 1
Syntax check	Ctrl + F2
Activate	Ctrl + F3
Run class	F9
Database table Data Preview	Alt + F8