SQL Server 2022 TRY_CONVERT and TRY_CAST Enhancements

SQL Server 2022 introduces enhancements to the TRY_CONVERT and TRY_CAST functions, providing more robust and reliable data type conversions. These enhancements improve data integrity and reduce errors in data transformations, making them invaluable tools for database administrators and developers. In this blog, we’ll explore these enhancements using the JBDB database and provide a detailed business use case to demonstrate their practical applications.

πŸ“Š Business Use Case: Data Quality Assurance in Financial Reporting

In our fictional company, JB Financials, maintaining high data quality in financial reports is crucial. The company uses a wide range of data sources, including legacy systems that often provide data in inconsistent formats. Ensuring accurate data conversion without losing critical information is essential for financial accuracy.

JB Financials has a table, FinancialData, that stores various types of financial information, including amounts in different currencies, dates, and other numerical values. The challenge is to convert this data into standardized formats for reporting purposes, while gracefully handling any conversion errors.

πŸ“‹ Table Schema: FinancialData

CREATE TABLE FinancialData (
    RecordID INT PRIMARY KEY,
    RawAmount VARCHAR(50),
    RawDate VARCHAR(50),
    CurrencyCode VARCHAR(10)
);

INSERT INTO FinancialData (RecordID, RawAmount, RawDate, CurrencyCode)
VALUES
(1, '1234.56', '2023-07-15', 'USD'),
(2, '1234,56', '15/07/2023', 'EUR'),
(3, '1,234.56', '07/15/2023', 'USD'),
(4, '1.234,56', '2023.07.15', 'JPY'),
(5, 'invalid', 'invalid', 'GBP');

πŸ”„ TRY_CONVERT and TRY_CAST Enhancements

The TRY_CONVERT and TRY_CAST functions in SQL Server 2022 have been enhanced to provide better handling of data conversion scenarios, especially with cultural settings and invalid data. These functions attempt to convert expressions to the specified data type and return NULL if the conversion fails, without raising an error.

Example: TRY_CONVERT

The TRY_CONVERT function attempts to convert the provided expression to the specified data type.

SELECT 
    RecordID,
    RawAmount,
    TRY_CONVERT(DECIMAL(10, 2), RawAmount, 1) AS ConvertedAmount
FROM FinancialData;

This query attempts to convert the RawAmount values to DECIMAL(10, 2) with style 1 (for converting strings with commas). The enhanced TRY_CONVERT gracefully handles invalid conversions, such as ‘invalid’ in the data, returning NULL instead of raising an error.

Example: TRY_CAST

The TRY_CAST function is similar to TRY_CONVERT but provides a more straightforward syntax for simple conversions.

SELECT 
    RecordID,
    RawDate,
    TRY_CAST(RawDate AS DATE) AS ConvertedDate
FROM FinancialData;

This query attempts to cast the RawDate values to the DATE data type. The TRY_CAST function will return NULL for the ‘invalid’ date format, avoiding potential runtime errors.

πŸ“ˆ Detailed Business Use Case: Data Standardization for Financial Reports

Scenario: JB Financials needs to standardize and validate the data in the FinancialData table before generating monthly financial reports. This involves converting the raw amount data to a standardized currency format and converting date strings to a standard DATE format.

Solution:

  1. Standardizing Amounts: Use TRY_CONVERT to convert the RawAmount to a DECIMAL type, ensuring proper handling of different number formats (e.g., commas and periods).
  2. Validating Dates: Use TRY_CAST to convert the RawDate to a DATE type, handling various date formats and invalid data.
  3. Generating Reports: Use the converted data to generate accurate financial reports.

Implementation:

SELECT 
    RecordID,
    TRY_CONVERT(DECIMAL(10, 2), RawAmount, 1) AS StandardizedAmount,
    TRY_CAST(RawDate AS DATE) AS StandardizedDate,
    CurrencyCode
INTO FinancialReports
FROM FinancialData
WHERE TRY_CONVERT(DECIMAL(10, 2), RawAmount, 1) IS NOT NULL
AND TRY_CAST(RawDate AS DATE) IS NOT NULL;

This query creates a new table, FinancialReports, with standardized and validated data. Only rows with successfully converted amounts and dates are included, ensuring high data quality for the reports.

πŸŽ‰ Conclusion

The TRY_CONVERT and TRY_CAST enhancements in SQL Server 2022 offer powerful tools for handling data type conversions, especially in scenarios with inconsistent or invalid data. By using these functions, JB Financials can standardize and validate their data, ensuring accurate and reliable financial reporting.

These enhancements reduce the risk of errors and improve the robustness of data transformation processes, making them essential for any organization dealing with diverse data sources and formats. Whether you’re handling financial data, customer information, or any other type of data, the TRY_CONVERT and TRY_CAST functions can help ensure that your data conversions are smooth and error-free.

Happy querying! πŸ˜ŠπŸš€

For more tutorials and tips on  SQL Server, including performance tuning and  database management, be sure to check out our JBSWiki YouTube channel.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided β€œAS IS” with no warranties, and confers no rights.

SQL Server Always On Series: Availability group DDL operations are permitted only when you are using the master database


Introduction

During a recent attempt to perform a manual failover from Always On Availability Group from JBSAG1 to JBSAG2 using Microsoft SQL Server Management Studio (SSMS), an unexpected error disrupted the process. The error, specifically identified as Microsoft SQL Server Error 35208, posed a challenge to the manual failover operation. In this detailed account, we’ll explore the encountered issue, outline the steps taken to address it, and ultimately achieve a successful manual failover.

Issue
Upon initiating the Always On Availability Group manual failover, the process encountered a hurdle with the following error:

TITLE: Microsoft SQL Server Management Studio
Manual Failover failed (Microsoft.SqlServer.Management.HadrTasks)

ADDITIONAL INFORMATION:
Failed to perform a manual failover of the availability group ‘JBSWiki’ to server instance ‘JBSAG2’. (Microsoft.SqlServer.Management.HadrModel)

For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.47021.0&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&LinkId=20476

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

Availability group DDL operations are permitted only when you are using the master database. Run the ‘USE master’ statement, and retry your availability group DDL statement. (Microsoft SQL Server, Error: 35208)
For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-35208-database-engine-error

Navigating through this error was the initial challenge, particularly when attempting the failover using the SSMS graphical user interface (GUI). Executing the ‘USE master’ statement in this context presented uncertainties, prompting a reevaluation of the failover approach.

Solution
To address the dilemma, the following steps were taken:

GUI Failover Attempt:

  • Initially, the failover was attempted through the SSMS GUI, raising questions about how to execute the ‘USE master’ statement within the graphical interface.

Scripted Failover Action:

  • The failover wizard was restarted, and instead of concluding the process through the GUI, the failover action was scripted for manual execution. I started the failover wizard again and this time instead of clicking finish at the end, tried scripting the failover action.

Manual Execution of Failover Command:

  • The failover command was manually executed from the SSMS SQLCMD query window, successfully completing the failover process.

Database Context Discovery:

  • Investigation revealed that the database context for a new query window was set to a user database (JBDB) instead of ‘master,’ leading to a pivotal realization. I tried clicking on a new query window and I saw that the database context for that query window was set to an user database JBDB and not master.

Connection Options Adjustment:

  • This is when I realized that I might have connected to the SQL Server instance with an User Database specified on the “Connect to database” in “Options <<” as part of making a connection from SSMS. Please check screenshot below,

After realizing this, I disconnected the existing sessions on SSMS and changed “Connect to database” in “Options <<” to “Master” and connected to SQL server JBSAG1 and JBSAG2.

Success After Correction:

  • Following these corrective actions, subsequent manual failover and failback attempts via SSMS were executed seamlessly.

Summary
In summary, this journey through troubleshooting manual failover with error 35208 underscored the importance of the database context, especially when initiating DDL operations. The solution involved a meticulous adjustment of connection options within SSMS, ensuring a connection to the ‘master’ database before attempting manual failover. This article provides a detailed account of the encountered challenge, the thought process behind the solution, and the successful resolution achieved through careful steps and insights.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided β€œAS IS” with no warranties, and confers no rights.