Clarify SupportStoredProceduresResult behavior across providers

docs/stored-procedures.md

@@ -4,6 +4,26 @@ Stored procedure support is available through `db.Procedures` when `DynamicDatab
 
 This page documents actual runtime behavior from `DynamicProcedureInvoker`.
 
+## `SupportStoredProceduresResult` and Provider Differences
+
+`DynamicProcedureInvoker` can treat the procedure "main result" as either:
+
+- affected rows from `ExecuteNonQuery()`
+- provider return value parameter
+
+This behavior is controlled by `DynamicDatabaseOptions.SupportStoredProceduresResult`.
+
+- `true`: if a return-value parameter is present, invoker uses that value as main result
+- `false`: invoker keeps `ExecuteNonQuery()` result (safer for providers that do not expose SQL Server-like return value behavior)
+
+Why this matters:
+
+- SQL Server commonly supports procedure return values in this style
+- some providers (for example Oracle setups) do not behave the same way
+- forcing return-value extraction on such providers can cause runtime errors or invalid result handling
+
+If procedures fail on non-SQL Server providers, first disable `SupportStoredProceduresResult` and rely on explicit `out_` parameters for status/result codes.
+
 ## Invocation Basics
 
 ```csharp
@@ -232,7 +252,11 @@ var code = (int)res.code;
 - Mapping to class fails silently (dynamic fallback):
   - ensure output model is mappable and keys match columns/properties
 - Return value not appearing:
-  - ensure `ret_` parameter is supplied, or enable provider option `SupportStoredProceduresResult`
+  - ensure `ret_` parameter is supplied
+  - ensure provider option `SupportStoredProceduresResult` matches your DB behavior
+- Procedure call errors on non-SQL Server providers:
+  - set `SupportStoredProceduresResult = false`
+  - return status via explicit `out_` parameters instead of return-value semantics
 
 ## Notes