How Many PreparedStatements and SQL Statements Execute in This JDBC Code?

Database applications with JDBC
Answer Correct answer: A, B — the JDBC code creates exactly two PreparedStatement objects but executes three SQL statements (one SELECT plus two updates) against the EMP data.

Given the data of the EMP table: Assuming that jdbcURL, username, and password are declared and initialised. Which two happen upon execution? (Choose two.) - image - image

  1. Three SQL statements are executed. Correct Answer
  2. Two PreparedStatement objects are created. Correct Answer
  3. Two SQL statements are executed.
  4. Memory leaks because Connection, PreparedStatements, and ResultSet are not closed.
  5. Three PreparedStatement objects are created.

Community Votes

AB
67%
BC
33%

67% of anonymous learners picked answer AB. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

You must separate PreparedStatement object creation from statement execution — the trap is assuming every execute call inside the loop needs a brand-new PreparedStatement (option E) or counting only distinct SQL strings (option C).

This 1Z0-819 JDBC question asks what actually happens when the EMP code runs — how many PreparedStatement objects are created and how many SQL statements are executed. The verdict is A and B: only two PreparedStatement objects are built, but three SQL statements hit the database.

Picking BC — learners count the two distinct SQL strings and call it two executed statements, forgetting that the re-parameterised PreparedStatement is executed a second time, which makes three actual executions.

Community Discussion (4 comments)

ASPushkin 👍 1 Selected: AB
Actually two cases if the table RECRUITING exists then answer AB if it doesn't answer BC if the tabel RECRUITING exists then three sql statements executed One for select and two for update in the loop
ASPushkin 👍 1
answer : BC C. is correct There are just two sql statements "SELECT oid, role FROM desp_roles WHERE role = ?" and "INSERT INTO RECRUITING (ID, NAME) VALUES(?, ?)" it is not clear about RECRUITING table if it doesn't exist then there is an java.sql.SQLSyntaxErrorException: Table 'kwikorder.recruiting' doesn't exist but anyway it was executed B. obviously thats right they are two prepared statements created query, update F. failed Connection and two PreparedStatements are automatically closed in tryWithResource exceptions. A ResultSet object is automatically closed when the Statement object that generated it is closed, re-executed, or used to retrieve the next result from a sequence of multiple results. actually there is just one ResultSet ResultSet rs = query.executeQuery(); it executed just one timeand closed automatically after Prepatred statements D. FAILED see F
cathDev 👍 1 Selected: AB
two SELECT queries and one INSERT INTO statement. It creates two PreparedStatement objects: “query” for the SELECT query and “update” for the INSERT INTO statement.
d7bb0b2 👍 1 Selected: BC
2 prepare statemt ok 2 statements are executed independently of the number of times

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

The code opens one Connection and prepares exactly two PreparedStatement objects: one bound to the SELECT that reads the EMP data and one bound to the data-modification statement run afterwards. That modification PreparedStatement is re-parameterised with setInt/setString and executed again for a second parameter set driven by the EMP rows, so the Connection sends one query plus two updates — three SQL statements in total. Because the same PreparedStatement object is reused instead of being rebuilt each pass, the object count stays at two, which is precisely what options A and B state. This is why the pair A+B describes the execution accurately while the alternatives mis-count one of the two dimensions.

Why the Other Options Are Wrong

Option C claims only two SQL statements are executed, which ignores the repeated execution of the already-prepared modification statement — the driver really does send three statements. Option D invents a memory leak: Connection, PreparedStatement and ResultSet are JDBC resources, and when the Connection is closed (as the shown code does) its statements and result sets are released, so nothing leaks. Option E confuses object creation with execution — calling executeQuery/executeUpdate repeatedly on the same PreparedStatement never creates a new PreparedStatement object, so 'three objects' cannot happen here. That leaves A and B as the only consistent pair.

Community Comment Notes

As cathDev explained, the code "It creates two PreparedStatement objects" — one for the SELECT and one for the DML statement — which immediately rules out option E. ASPushkin frames the same arithmetic from the execution side, describing one SELECT and "two for update in the loop", i.e. three executed statements, while also warning that the count collapses if the target table does not exist and the insert fails. The 67-to-33 vote split between AB and BC reflects exactly this tension: counting every execution (A) versus counting only distinct SQL strings (C).

Official Reference

Exam Strategy

For JDBC 'what happens upon execution' questions, count two things on separate lines of scratch paper: the number of distinct PreparedStatement/Statement objects created (a constructor/prepareStatement call) and the number of executeQuery/executeUpdate/executeBatch calls. The distractors almost always swap these two counts, so verify that your chosen pair matches the 'Choose two' instruction.

Frequently Asked Questions

Why is option E (three PreparedStatement objects) wrong for this JDBC code?

The PreparedStatement is prepared once and then reused with new setInt/setString parameters before each executeUpdate, so only two objects exist even though it is executed more than once.

Why is option D (memory leaks) not the answer?

No resource is abandoned: JDBC releases a Connection's Statements and ResultSets when the Connection is closed, which the shown code does, so no leak occurs.

More 1Z0-819 FAQ →

Related Analysis

← Back to 1Z0-819 Study Guide