Runtime Error 17: “Can't perform requested operation,” explained and fixed

Error 17, “Can't perform requested operation”, is deliberately vague: the object or system understood the request and refused it in its current state. Typical cases are acting on a file or recordset that is not in the state the operation needs, or asking a control to do something its mode forbids. The error text gives no hint, so the fix starts with identifying exactly which line and which object's state made the request impossible.

For people who just run the program

  1. Note the exact step. With a message this generic, the step is the diagnosis: saving, printing, opening, and refreshing each point at a different object in a wrong state.
  2. Check the obvious state first. Is the file open elsewhere, the record being edited by someone else, the device busy? Error 17 often clears when the conflicting use ends.
  3. Retry once after closing and reopening the document. Objects left in a half-finished state by an earlier failure are a common cause, and a clean restart resets them.
  4. Report the step and anything else using the same file or data. “Only happens while the shared copy is open” is the clue that cracks this one.

For people who write the code

  1. Print Err.Source and the line. Error 17's description is useless by design; the Source property and the failing statement are what identify the refusing object.
  2. Verify state before acting. Check State on recordsets and connections, Visible/Enabled where relevant, and whether the previous operation actually completed instead of assuming it did.
    3. If rs.State = adStateOpen Then rs.Close   ' acting on a closed recordset
rs.Open sql, cn                            ' is a classic error 17
  3. Suspect sequencing after a trapped error. Code that catches an error and continues often leaves an object half-open; the next operation then fails with 17 while the real bug sits in the handler above it.
Because error 17 is generic, some libraries raise it for their own failures too. Before redesigning around it, confirm with a minimal test whether the refusal comes from VBA, the host application, or a component, and log Err.Source every time it fires.

If it still happens

If the operation succeeds in isolation but fails in the full macro, something earlier changed the object's state: a prior open that was never closed, a transaction left hanging, a modal dialog still up. Step through with the state of the suspect object in the Watch window and compare the passing and failing runs.

Common questions

Why is error 17 so vague? It is a catch-all refusal used when an operation is invalid for the object's current state and no more specific error exists. The remedy is identifying the object and state, which is why Err.Source matters.

Is error 17 a permissions problem? Usually not. Permission failures have their own numbers (70 and 75). Error 17 is about state: the operation is not allowed right now, on this object, in this condition.

Related errors

Runtime Error 68 · Runtime Error 75 · Runtime Error 71