V2 SQL Driver settings

   

proiv dashboard  

The V2 driver is an optional, updated SQL Server driver for PROIV. It was introduced because Microsoft is deprecating support for SQL cursors. V2 uses key-based updates instead of SQL cursors, ensuring continued compatibility with current and future versions of SQL Server.

How Does V2 Differ from V1?

Feature

V1 Driver (Default)

V2 Driver (Optional)

Update Mechanism

SQL Cursor

WHERE clause with key values

Row Targeting

Always precise

Depends on key uniqueness

Locking Model

Pessimistic only

Optimistic or Pessimistic (user choice)

Concurrency Handling

Serializes updates

May allow parallel or conflicting writes (only with optimistic locking)

Risk of Multi-Row Update

Low

Higher if key is non-unique

Locking Models Explained

Pessimistic Locking (V1 and V2 with Locking Hints Enabled)

Optimistic Locking (V2 with Locking Hints Disabled)

Important:

V1 and V2 (with pessimistic locking enabled) are designed to be functionally equivalent. Both provide the same level of safety and data integrity. Switching to V2 is optional for now, but may become the default in future release. For now, V1 is still fully supported and still the default driver.

Optimistic locking (V2 with locking hints disabled) is available as a choice for users who want greater concurrency and potential performance benefits, but it comes with different risks and is not the default.

Locking Hints and Isolation Levels

How to Enable the V2 Driver and Choose a Locking Model

You can enable the V2 driver in the PROIV Dashboard under SQL Server Advanced Options. After enabling V2, you can choose your preferred concurrency (locking) model by setting the relevant options:

You can switch back to the default driver (V1) at any time if needed. In the future, if Microsoft deprecates cursor support, V1 will also be deprecated and V2 will become the standard.

What Should Users Expect?

Understanding "Select For Update" and "Enable Locking Hints"

Both of these options are set in the PROIV Dashboard:

What happens if you only enable one?

Best Practice:

For safest and most predictable behaviour, always enable both "Select For Update" and "Enable Locking Hints" in the PROIV Dashboard. This ensures proper row locking and data integrity during updates.

Best Practices:

  1. Use Primary Keys for Updates: Always update using the primary key or a unique alternate index.

  2. Avoid Non-Unique Alternate Indexes: Do not use alternate indexes for updates unless they include all primary key fields.

  3. Fallback to V1 Driver: If you are unsure, use the default V1 driver to retain cursor-based behaviour.

  4. Test Your Updates: Make sure your test cases cover updates via alternate indexes, partial key selections, and concurrent update scenarios.   

Workarounds:

If you experience unexpected behaviour (such as updates affecting multiple rows or errors when using non-unique keys):

Frequently Asked Questions

Q: Why was the V2 driver introduced?

A: Microsoft is deprecating SQL cursors. V2 ensures your system remains compatible.

Q: Will my updates always target the correct row?

A: With V2, updates are precise if you use a unique key. If you use a non-unique key, multiple rows may be updated.

Q: What happens if two users update the same row at the same time?

A: With V2 in optimistic mode, both updates may proceed in parallel. The last update to commit will be the one that remains. With pessimistic mode (locking hints enabled), one user waits for the other to finish.

Q: Can I switch back to V1 if I have problems?

A: Yes. Simply change the setting in the PROIV Dashboard.

Q: Is V2 enabled by default?

A: No. You must explicitly select V2 in the Dashboard.

Q: What do "Select For Update" and "Enable Locking Hints" do?

A: "Select For Update" locks rows for updates, preventing conflicting changes. "Enable Locking Hints" adds SQL Server-specific hints to queries, controlling how data is locked and affecting concurrency.

Q: How do isolation levels affect locking?

A: The isolation level (such as READ_COMMITTED or SNAPSHOT) determines how SQL Server handles concurrent reads and writes. Locking hints can override or modify this behaviour, affecting whether you see uncommitted data or experience blocking.   

 

V2 SQL Driver Configuration

The V2 SQL Driver for Microsoft SQL Server offers high compatibility with the existing "DEFAULT" driver but with potential gains in performance. It moves away from using cursors when processing records in PROIV to using explicit criteria for the keys.

The V2 SQL Driver uses the same locking hints as the "DEFAULT" driver and supports the PROIV transaction locking model. Its behaviour in some non-default configurations (different transaction isolation level etc) of the Microsoft SQL driver may differ from "DEFAULT". It is the user's responsibility to check the behaviour of the V2 SQL Driver is acceptable in their application. The existing "DEFAULT" Microsoft SQL Driver will continue to be supported can be reverted back to.

Care must be taken when creating an alternate index to update a SQL file: see Alternate Index Mapping. As the V2 SQL Driver will use the keys of the alternate index as criteria for SQL statements and not the keys of the SQL table.

  1. Use Primary Keys for Update  - Always perform updates using the primary key or a unique alternate index.

  2. Avoid Non-Unique Alternate Indexes - Do not use alternate indexes for updates unless they include all primary key fields.

  3. Update Logic Pattern  - Select using alternate index if needed.

                                            - Update using primary key to ensure uniqueness.

 

 

Related Topics

Configuring Virtual Machine Settings

Comment on this topic

Topic ID: 700062