What is MySQL Error Code 1005?

SQL error 1005, also known as “Can’t create table (errno: 150)”, is a MySQL error that occurs when there is a problem with a foreign key constraint. Foreign key constraints are used to establish relationships between tables in a relational database. They ensure that data integrity is maintained by preventing actions that would create inconsistent or invalid data.

Possible Causes

When you encounter SQL error 1005, MySQL is telling you that there is an issue with a foreign key constraint while trying to create or modify a table. This error can be caused by a variety of reasons, such as:

1. Incorrect syntax: The foreign key constraint might not be defined properly, leading to a syntax error in your SQL statement.
2. Data type mismatch: The data types of the columns involved in the foreign key constraint must match exactly. If there is a mismatch in data types, MySQL will throw error 1005.
3. Missing referenced table: The table referred to in the foreign key constraint might not exist in the database.
4. Incompatible foreign key constraint: The referenced table might have a foreign key constraint with incompatible attributes, such as different collation, character set, or storage engine.
5. Circular reference: A circular reference occurs when two or more tables reference each other with foreign key constraints, creating a loop. MySQL does not allow circular references, and it will result in error 1005.

Fix MySQL Error Code 1005

Now that we have a basic understanding of SQL error 1005 and its possible causes, let’s dive into the solutions to fix this issue.

1. Check for typos or errors in your table definitions: Make sure that you have correctly defined your table columns, data types, and constraints. Double-check for any misspellings, missing or extra commas, and other syntax errors in your table definitions.
2. Ensure that referenced columns and tables exist: If you are defining foreign key constraints, make sure that the referenced columns and tables actually exist in the database. If the referenced table has not been created yet, or if it has been dropped or renamed, you may encounter error code 1005.
3. Check for conflicting constraints: If you have multiple foreign key constraints in your table definitions, ensure that there are no conflicts. For example, if you have two foreign keys that reference the same column in another table, MySQL will raise error code 1005. Make sure that your constraints are properly defined and do not conflict with each other.
4. Verify data types and lengths: Make sure that the data types and lengths of the columns in your foreign key and referencing tables match exactly. Data type mismatches can result in error code 1005.
5. Disable foreign key checks: You can temporarily disable foreign key checks in MySQL by running the following command before creating or modifying tables: SET FOREIGN_KEY_CHECKS = 0;. This can help you identify and fix any issues with foreign key constraints. However, be cautious when using this approach, as it can potentially lead to inconsistent data if not used properly.
6. Check for circular references: If you have circular references in your foreign key constraints, where Table A references Table B and Table B references Table A, you will encounter error code 1005. To fix this issue, you may need to restructure your database schema to remove circular references.
7. Check for storage engine compatibility: If you are using different storage engines for your referencing and referenced tables, you may encounter error code 1005. Make sure that the storage engines are compatible, such as using InnoDB for both tables, as some storage engines do not support foreign key constraints.
8. Review MySQL error logs: Check the MySQL error logs for any additional information on the cause of the error. The error logs may provide more detailed information about the specific issue that is causing error code 1005.

By following these steps, you should be able to identify and fix the issue that is causing MySQL error code 1005. If you are still encountering issues, it may be helpful to consult the MySQL documentation or seek assistance from a knowledgeable database administrator.

Read More articles:

• How to fix SQL Error 1064: You have an error in your SQL syntax
• How to Fix SQL Server Error 207 – Invalid Column Name

The post How to Fix SQL Error 1005: A Comprehensive Guide appeared first on Techyaz.com.

In this article, we will explore what this error means, its possible causes, and provide solutions to fix it.

What is SQL Server Error 207 – Invalid Column Name?

SQL Server error 207 occurs when a column name referenced in a SQL query does not exist in the specified table or view. In other words, SQL Server is unable to find a column with the name mentioned in the query, and as a result, throws the error message “Invalid Column Name.”

Possible Causes

1. Typographical errors: One of the most common causes of error 207 is a typographical error in the SQL query. For example, misspelling a column name, using the wrong case, or forgetting to enclose the column name in square brackets, especially if the column name contains spaces or special characters.
2. Missing or renamed column: Another possible cause of error 207 is that the column may have been deleted or renamed in the table or view, but the query has not been updated accordingly. If a column is dropped or renamed, any queries that reference that column will result in error 207.
3. Scope and visibility of column: The visibility and scope of a column can also cause error 207. If a column is referenced in a query outside of its scope or visibility, SQL Server will not be able to find it, and the error will be thrown.
4. Schema changes: Changes to the schema of a table or view, such as adding, modifying, or deleting columns, can also result in SQL error 207 if the query has not been updated to reflect the changes.
5. Permissions: Another possible cause of SQL error 207 is insufficient permissions. If the user executing the query does not have the necessary permissions to access the column, SQL Server will throw the error.

Fix SQL Error 207

Now that we understand the causes of SQL Server Error 207, let’s explore some solutions to fix this issue:

1. Double-check the column name: The first step in fixing error 207 is to double-check the column name referenced in the SQL query. Make sure it is spelled correctly, using the right case, and enclosed in square brackets if needed. Pay attention to any spaces or special characters in the column name.
2. Verify column existence and visibility: Ensure that the column actually exists in the specified table or view and is visible to the user executing the query. If the column has been deleted or renamed, update the query accordingly.
3. Update the query: If the error is caused by changes to the schema of a table or view, update the query to reflect the changes. For example, if a new column has been added, make sure to include it in the SELECT, INSERT, UPDATE, or DELETE statements as needed.
4. Check permissions: Verify that the user executing the query has the necessary permissions to access the column. Make sure the user has SELECT, INSERT, UPDATE, or DELETE permissions on the table or view that contains the column.
5. Use aliases and table qualifiers: When referencing columns in a query, it is a good practice to use aliases or table qualifiers to avoid ambiguity. For example, instead of just using “SELECT column_name FROM table_name,” use “SELECT t.column_name FROM table_name AS t” or “SELECT table_name.column_name FROM table_name.”
6. Test and debug: After making any changes to the query or schema, always test and debug the query to ensure that the error has been resolved. Use SQL Server tools such as SQL
7. Use Schema Prefix: If you are referencing a table or column that belongs to a specific schema, make sure to include the schema name as a prefix in your SQL query. For example, if you have a table named “Customers” in the “Sales” schema, your query should be something like “SELECT * FROM Sales.Customers” instead of just “SELECT * FROM Customers”.
8. Resolve Ambiguous Column Names: If you encounter an ambiguous column name error, you need to specify which table the column belongs to in your SQL query. You can do this by prefixing the column name with the table name or alias in your query, e.g., “SELECT Orders.OrderID FROM Orders, Customers WHERE Orders.CustomerID = Customers.CustomerID” instead of just “SELECT OrderID FROM Orders, Customers WHERE CustomerID = Customers.CustomerID”.
9. Check Table Existence: Ensure that the table mentioned in your SQL query actually exists in the database. If not, you may need to create the table or correct the table name in your query.
10. Verify Schema Ownership: If you are referencing a table in a different schema, make sure that the schema exists and that you have the necessary permissions to access it. If not, you may need to create the schema or obtain the required permissions.

We learn about fixing SQL Server Error 207 which occurs when a SQL query references a column that does not exist in the specified table or view. This error typically results from a misspelled column name or a reference to a non-existent column in a SELECT, UPDATE, or DELETE statement. When the SQL Server query processor encounters an invalid column name, it raises SQL Error 207 and prevents the execution of the query. You can prevent this issue by following the steps given in this article.

Read More articles:

• How to fix SQL Error 1064: You have an error in your SQL syntax
• SQL Server Interview Questions & Answers on Indexes

The post How to Fix SQL Server Error 207 – Invalid Column Name appeared first on Techyaz.com.

What is SQL Error 1045?

Error 1045 is a MySQL error code that indicates a failed connection to the MySQL database server. The error message associated with SQL Error 1045 typically reads “Access denied for user ‘username’@’localhost’ (using password: YES)” or “Access denied for user ‘username’@’hostname’ (using password: YES)“.

This error occurs when a user attempts to connect to a MySQL database but does not have the proper authorization or has entered incorrect login credentials.

Possible Causes

There are several potential causes for SQL Error 1045, including:

1. Incorrect username or password: One of the most common causes of SQL Error 1045 is entering incorrect login credentials, including the username or password. It is essential to double-check and ensure that the correct username and password are entered when connecting to the MySQL database.
2. Missing or improper privileges: Another possible cause of SQL Error 1045 is the absence of the necessary privileges for the user trying to connect to the MySQL database. If the user does not have the proper privileges, they will be denied access, resulting in the error.
3. Hostname or IP address mismatch: MySQL uses hostnames or IP addresses to identify which hosts are allowed to connect to the database. If the hostname or IP address specified during the connection attempt does not match the one defined in the MySQL configuration, SQL Error 1045 may occur.
4. Firewall or security settings: Firewalls or security settings on the server hosting the MySQL database may block incoming connections, resulting in SQL Error 1045. It is essential to check the server’s firewall and security settings to ensure that they are configured correctly to allow MySQL connections.
5. MySQL server configuration issues: Incorrect configuration settings in the MySQL server can also lead to Error 1045. For example, if the MySQL server is not configured to allow remote connections, users may encounter this error when trying to connect from a remote host.

Fix SQL Error 1045

Fixing SQL Error 1045 requires identifying the root cause of the issue and taking appropriate steps to rectify it. Here are some common solutions to fix Error 1045:

Verify Your Credentials

The first step in resolving SQL Error 1045 is to verify that you are using the correct credentials to connect to your database server. Double-check the username and password you are using in your database connection settings or in your SQL command. Ensure that you are using the correct username and password combination that has the necessary privileges to access the database.

Check for Typos

Sometimes, a simple typo in your username or password can result in SQL Error 1045. Make sure that you have spelled your username and password correctly, paying attention to uppercase and lowercase letters. Also, check for any special characters or spaces that may have been mistakenly included in your credentials.

Grant Sufficient Privileges

If you are still unable to connect to the database and receive SQL Error 1045, it could be due to insufficient privileges for the user account you are using. To fix this, you can grant the necessary privileges to the user account. Log in to your database server as a privileged user, such as the root user, and execute the following SQL command:

GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost'IDENTIFIED BY 'password';

Replace ‘username’ with the actual username you are using to connect to the database and ‘password’ with the actual password for that user.

This command grants all privileges on all databases and tables to the specified user account when connecting from the localhost. If you are connecting from a remote host, you may need to replace ‘localhost’ with the appropriate hostname or IP address.

Check hostname or IP address

Verify that the hostname or IP address specified during the connection attempt matches the one defined in the MySQL configuration. If necessary, update the MySQL configuration to reflect the correct hostname or IP address

Update Your Password

If you recently changed the password for the user account you are using to connect to the database and forgot to update your connection settings, it could result in SQL Error 1045. In this case, you can simply update the password in your connection settings or in your SQL command to match the new password. If you are using a MySQL or MariaDB command-line client, you can update the password using the following SQL command:

ALTER USER 'username'@'localhost'IDENTIFIED BY 'new_password';

Replace ‘username’ with the actual username you are using and ‘new_password’ with the new password you want to set.

Check for Firewall or Network Issues

Firewall or network issues can sometimes block the connection to the database server and result in Error 1045. Make sure that the port used by your database server (default is 3306 for MySQL and MariaDB) is open in your firewall and that there are no network connectivity issues between your client and the database server.

Reinstall or Reconfigure MySQL or MariaDB

If all else fails and you are still unable to fix SQL Error 1045, you may need to reinstall or reconfigure your MySQL or MariaDB server. This should be done with caution, as it may result in data loss or other unintended consequences. Before proceeding with a reinstallation or reconfiguration, make sure to backup your database and configuration files to prevent any potential data loss.

In conclusion, SQL Error 1045 can be a frustrating issue to encounter when trying to connect to your MySQL or MariaDB database server. However, by following above steps you can fix this issue.

Read More articles on SQL errors:

• Fix the Most Common SQL Syntax Error: SQL Error 1064

The post How to Fix SQL Error 1045: Resolving Access Denied Issues appeared first on Techyaz.com.

SQL Server Error 18456, also known as the “Login failed for user” error, is a common authentication error that occurs when a user fails to log in to SQL Server. The error message associated with Error 18456 usually reads:

“Login failed for user ‘<username>’. (Microsoft SQL Server, Error: 18456)”

The error occurs when SQL Server is unable to authenticate the user trying to connect to the SQL Server instance. There are several reasons why this error may occur, including incorrect login credentials, disabled user accounts, expired passwords, or issues with SQL Server authentication settings.

How to Fix SQL Server Error 18456?

Fixing SQL Error 18456 requires identifying the root cause of the error and applying the appropriate solution. Here are some common solutions to fix SQL Error 18456:

1. Verify Login Credentials: The most basic step in fixing SQL Server Error 18456 is to verify that the login credentials, including the username and password, are correct. Make sure you are entering the correct login credentials for the SQL Server instance you are trying to connect to.
2. Enable Mixed Mode Authentication: SQL Server supports two types of authentication modes – Windows Authentication mode and Mixed Mode (Windows Authentication and SQL Server Authentication) mode. If you are using SQL Server Authentication, make sure that Mixed Mode Authentication is enabled in SQL Server. You can do this through SQL Server Management Studio (SSMS) by right-clicking on the SQL Server instance, selecting Properties, and then navigating to the Security tab.
3. Check User Account Status: Ensure that the user account you are trying to log in with is not disabled or locked out. If the user account is disabled or locked out, unlock or enable the account using SQL Server Management Studio or SQL Server command-line tools.
4. Reset Password: If you suspect that the password for the SQL Server login is incorrect or has expired, reset the password. You can do this through SQL Server Management Studio or by using the ALTER LOGIN statement in SQL Server.
5. Check SQL Server Error Logs: SQL Server logs detailed information about authentication failures in its error logs. Review the SQL Server error logs to identify any specific error messages related to Error 18456. The error logs may provide additional insights into the root cause of the issue.
6. Verify SQL Server Permissions: Ensure that the user account has the necessary permissions to log in to the SQL Server instance. Check the server-level and database-level permissions for the user account and grant the appropriate permissions if necessary.
7. Check Firewall Settings: If you are connecting to a remote SQL Server instance, verify that the appropriate ports are open in the firewall to allow communication between the client and the server. Check the firewall settings on both the client and server machines to ensure that they are not blocking the required ports.
8. Check SQL Server Version: Error 18456 can also occur if there is a version mismatch between the SQL Server client and server components. Ensure that the SQL Server client version matches the server version to avoid compatibility issues.
9. Apply SQL Server Service Packs and Cumulative Updates: Microsoft regularly releases service packs and cumulative updates for SQL Server that address known issues and provide bug fixes.

You can also read the below articles to fix SQL error 18456:

• Fix SQL Error 18456: failed to open the explicitly specified database
• Fix SQL Server Error 18456: Login failed for user ‘User_Name’.
• Fix Error 18452: Login failed. The login is from an untrusted domain

The post How to Fix SQL Server Error 18456: A Comprehensive Guide appeared first on Techyaz.com.

What is SQL Error 1064?

SQL Error 1064 is a syntax error that occurs when you execute an SQL query with incorrect syntax. It’s a common mistake that can happen to anyone, regardless of their level of expertise in SQL or MySQL. The error message typically looks something like this:

“Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘…’ at line …”

Next, we will understand why we get this SQL syntax error and what steps we can take to fix or avoid it.

Fix SQL Syntax Error 1064

This error can be frustrating, but the good news is that it’s usually easy to fix once you identify the cause. Here’s how you can go about fixing SQL Error 1064:

1. Double-check your SQL query: The first step in fixing SQL Error 1064 is to thoroughly review your SQL query. Check for any typographical errors, missing or misplaced keywords, and incorrect syntax. Make sure that all the SQL statements in your query are properly terminated with semicolons, and that you have used the correct quotation marks (single or double) for string literals.
2. Review reserved keywords: MySQL has reserved keywords that have special meanings in SQL queries. If you inadvertently use a reserved keyword as a column or table name in your query without properly escaping it, you may encounter SQL Error 1064. To fix this, either choose a different name for your column or table, or enclose the reserved keyword in backticks (`) to escape it.
3. Check for mismatched parentheses or quotes: Another common cause of SQL Error 1064 is mismatched parentheses or quotes. Make sure that all opening and closing parentheses and quotes in your query are properly balanced. If you have multiple levels of nested parentheses, it’s easy to miss a closing parenthesis, causing a syntax error. Similarly, ensure that all quotes used in your query are properly paired, whether they are single or double quotes.
4. Verify table and column names: Check that you have used the correct table and column names in your query. Make sure that the names are spelled correctly, and that they match the actual names of your database objects. If you are using aliases for table or column names, ensure that they are used consistently throughout your query.
5. Validate data types and values: If you are inserting or updating data in your MySQL database, verify that you are using the correct data types and values for your columns. For example, if you are inserting a string value into a numeric column, or vice versa, you may encounter this SQL Syntax Error 1064. Make sure that the data types of your columns match the values you are trying to insert or update.
6. Use a SQL editor or IDE: Working with a SQL editor or Integrated Development Environment (IDE) can greatly help in identifying syntax errors. These tools often provide syntax highlighting, code completion, and error checking features that can help you spot and fix SQL errors more easily.
7. Consult the MySQL documentation: If you’re still unable to identify the cause of this SQL syntax error, consult the official SQL documentation in case you are using MySQL database. MySQL has extensive documentation that provides comprehensive information on SQL syntax, reserved keywords, data types, and other topics. You can search the documentation for specific keywords or browse through the documentation to learn more about SQL syntax and best practices
8. Test your SQL query: If you are still encountering SQL error 1064, try executing your query in a controlled test environment, such as a local development server or a database sandbox, to isolate and identify the issue. You can also try breaking down your query into smaller parts and testing them individually to identify the specific portion of the query that is causing the error.

If you are unable to fix the SQL error 1064 on your own, you may need to seek assistance from a database administrator (DBA) or a knowledgeable colleague who has experience with SQL queries and SQL syntax errors.

Read More articles:

• How to Prepare for a Job Interview?
• Fix SQL Error 18456: failed to open the explicitly specified database

The post How to fix SQL Error 1064: You have an error in your SQL syntax appeared first on Techyaz.com.

Login Failed – Error: 18456, Severity: 14, State: 38

Reason: Failed to Open the Explicitly Specified Database

Fix Error “Failed to Open the Explicitly Specified Database”

The error log is saying “Failed to Open the Explicitly Specified Database“, it means either your have specified wrong database in your connection string or your login does not have access to the specified database. You can validate below options to isolate this issue.

• Check whether you have specified correct database in your connection string or not
• If you are using correct database then whether the login you are using to establish database connection has access to this specified database or not.
• Correct if you find something in any of the above two options.
• Check login properties whether it is using correct database as default database configuration or not. If correct database is defined then login has access to that database or not. I will explain about this step in below section as well.
• You should also check whether number of connections to the database is exhausted or not. Review your maximum number of connections setting.
• Ensure your database is not set to AUTO CLOSE setting or not inaccessible. Database should be online and healthy state to accept connections.
• Make sure you have a trust between both machines, database server and the machine from where you are trying to connect. I would suggest you to read below article as well where i have explained various steps to troubleshoot SQL Server connection issues.

Read more articles on SQL error 18456 and connection issues:

• How to Fix SQL Server Error 18456: A Comprehensive Guide
• How to fix SQL Server error 53 – Not able to open database connection
• Fix SQL Server error 18456 – Login failed for user

Let’s learn how to check default database settings for a SQL Server login and a user mapping for any database to the login.

Check Login Properties

The solution to fix this issue can also come by reviewing the properties of this login. Launch its properties window and change the default database to the correct one if this setting is showing wrong database. Sometimes, we drop the databases from the SQL Server instances but never update other objects. If this login is not showing any database and it is showing blank then click at its drop-down to choose your desired database as the default database for this login. Click on Ok button to apply that change. You will stop getting this issue after making this change.

You can open login properties windows by right click at the identified login and then choose properties from dropdown options.

Sometimes, you have chosen the default database as “master” but your login doesn’t have connect permission on master database so ensure you have at least connect permission on the database which you are choosing as the default database for your login. You can click at “User Mapping” tab from left side pane of the login properties window. You will get all databases in top side of right side pane and level of access in bottom side pane. Click at your database from right side pane along with its level of permission which you want to assign. Click at Ok button to apply this change.

Have a look at below screenshot to understand default database of a login and from where you can access User Mapping tab to provide appropriate access to your database. Your login should have access to both databases, the one mentioned as default database for your login and the specified database in connection strings.

You can fix SQL error “Failed to Open the Explicitly Specified Database” by following above steps. Write your feedback if you have fixed this issue by other way. I will update this article accordingly with credits.

The post Fix SQL Error 18456: failed to open the explicitly specified database appeared first on Techyaz.com.

A connection timeout has occurred on a previously established connection to availability replica ‘manvendradbggp03’ with id [availability group id]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

You may also receive similar issue under different alwayson error 35201. Below error will generate while attempting to establish the connection to availability group but failed because of connection timeout error 35206. The error text of this SQL error 35201 is given below.

A connection timeout has occurred while attempting to establish a connection to availability replica ‘manvendradbggp03’ with id [availability group id]. Either a networking or firewall issue exists, or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

If you are always getting above issues and unable to establish any connection to its respective availability replica then you should immediately look in to network side whether there is poor network latency, any network packet drop issue or firewall is blocking some connections or not as suggested in error code. But if you are getting this issue on intermittent basis then you should keep reading this article to understand more about alwayson error 35206.

SQL Server Error 35206 and Error 35201 in Always on

Both errors come because of connection timeout error between their respective replicas. Microsoft has categorized these errors as product issue and released cumulative updates to fix them. You should also consider these cumulative updates as per your SQL Server version. These issues will be very problematic if you will not address them on time because of below reasons:

• Availability databases will stop synchronizing. This could be a risk of potential data loss.
• Log file will start growing on your primary replica. This could be a potential risk for an outage if we will not address this issue on time.
• Frequent repetitive alerts for your critical systems

You must fix this issue by applying the cumulative update to avoid above problematic scenarios. But if you already have applied these updates and are still facing these issues then i would recommend you to read below section to try out other options.

Fix Always on Connection Timeout SQL Error 35206

Generally, this problem encounters only on high end systems where you have more than 24 cores CPU and SQL Server is highly transactional. One very simple workaround to overcome this issue is to restart SQL Server service on your secondary replica where you are getting this issue. Don’t restart SQL Server on primary replica. Restarting SQL Server on impacted availability replica will surely fix the issue for the time being.

Additionally, you should consider below checks to review and make changes accordingly as per your system design if you are still getting this issue on frequent basis.

Use Default Network Packet Size

Review network packet size configuration in SQL Server. Microsoft suggested to keep network packet size configuration with default value but sometime we make changes as per our need and forgot to revert these changes to their original values so i would recommend to revert this change to its default value. Read below article if you want to learn how to change network packet size configuration in SQL Server.

• How to Change Network Packet Size in SQL Server?

You should also consider evaluating your network bandwidth and firewall settings to make sure and isolate the issue. I would suggest you to work with network engineer on this front to review network or firewall related configurations.

Review Connection Timeout Setting

Another option i would recommend you to evaluate and review the session or connection time out settings. Make sure that session timeout setting for your always on configuration must be more than or equal to 10 seconds. You can consider increasing session time out if you have slow network between your replicas. Although if you are running highly transactional databases on high end box i assume you already have good network bandwidth but nothing wrong in reviewing the settings. Read below article if you want to reconfigure or change session time out in always on availability group.

• How to Change Session Timeout in Always on Availability Group Configuration?

If you are running your always on availability group configuration between multi subnet environment then i would recommend you to read attached Microsoft article to fix connection timeout errors in multi subnet availability groups.

Read More:

• Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group
• SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error
• Fix SQL Server Error 19471: Listener issue that came during Configuring SQL Server AlwaysOn Availability Group
• SQL Server Alwayson Interview Questions & Answers

The post Fix Always ON Connection Timeout Error 35206 in SQL Server appeared first on Techyaz.com.

Azure Data Studio is cross-platform database management tool to manage on prem as well as cloud based SQL Server deployments on windows, Linux and MacOS platforms. This tool offers a modern editor experience with IntelliSense, code snippets, source control integration, and an integrated terminal.

When you launch Azure Data Studio first time, it will show you a popup window and ask you to enable the preview features. You can choose “Yes” to use preview features and “No” to disable this feature. If this settings is disabled in your Azure Data studio then you can enable it anytime by accessing settings tab given bottom left of the Azure Data Studio screen. Below is the list of preview features for SQL Server in Azure Data Studio.

• Azure portal integration
• SQL Server Backup and Restore
• Deployments of SQL Edge, SQL Server Big Data Cluster, SQL Server container image & SQL Server on Windows
• SQLCMD mode
• Admin Pack for SQL Server
• Azure Synapse Analytics Insights
• Central Management Servers
• Database Administration Tool Extensions for Windows
• Kusto
• Language packs
• PostgreSQL
• PowerShell
• Query History
• SandDance for Azure Data Studio
• Server Reports
• SQL Assessment
• SQL Server Agent
• SQL Server Profiler
• Machine Learning
• Managed Instance Dashboard
• Visual Studio IntelliCode
• whoisactive

Above list is not limited to only given features. I was restoring a database using Azure Data Studio. When i tried to click at restore button, another popup window came and suggested to enable preview features for this restore as shown in below image. When you try to preform any above activity in Azure Data studio, you will get similar popup window.

I will show you step by step process to enable or disable preview feature in Azure Data Studio.

Enable Preview Features

I was trying to perform a database restore using Azure Data Studio and got a popup which was saying ” You must enable preview features in order to use restore “. Follow below steps to get it done.

• Launch Azure Data Studio
• Click at the setting button given bottom left of the screen, then again click at the setting options from displayed menu.

• Type Enable Preview Features from search bar given on the screen.
• You will get few options in drop down. Click at checkbox for Enable unreleased preview features under Workbench: Enable Preview Features.

• This change will automatically been saved in Azure Data Studio.

Now, you are good to go ahead and use all features which are in preview as per your need.

Disable Preview Features

Disabling preview features in Azure Data Studio is similar to above steps. You just need to uncheck the checkbox which you have checked in above step. Follow below steps to get it disabled.

• Launch Azure Data Studio
• Click at the setting button given bottom left of the screen. You will get a list of options from which you need to click at the settings options again.
• Type “Enable Preview Features” from search bar given on the screen.
• You will get few options in drop down. Uncheck the checkbox for Enable unreleased preview features
• This change will automatically been saved in Azure Data Studio.

You have learnt preview features enablement and how to disable it in Azure Data Studio.

Read More Articles:

• Cloud Security – How to Secure Cloud Environment?
• SQL Server Interview Questions & Answers on Indexes
• How to Learn Cloud Computing?
• What is Cloud Computing

The post How to Enable Preview Features in Azure Data Studio appeared first on Techyaz.com.

A transport-level error has occured when receiving results from the server. (provider: TCP Provider, error: 0 – The semaphore timeout period has expired.) (Microsoft SQL Server, Error:121)

This was an intermittent issue and when we were executing the script from other server it was not throwing any issue. I did some research on this and found out that this error came because of unstable network connectivity.

SQL Server Error 121 The Semaphore Timeout Period Has Expired – Root Cause

There are various parameters that can affect network connectivity like network adaptors, packet drop, configured packet size etc. So i would suggest first you should connect to your network team and ask them to look into this issue. If network team has not found anything then you need to check application level network configurations at your level.

You should ask some questions to your network resource like whether any network packet drop being observed or not, or is there any NIC card issue etc. Let’s assume you have already reached out to network team and they haven’t found anything. I would suggest you to look into below options at your level to make sure everything is in place and not misconfigured.

• Check TCP\IP settings
• Ensure you have appropriate network packet size configured in SQL Server
• Make sure you have properly configured TCP Chimney Offload
• Validate you don’t have Network Interface Card (NIC) driver issue, you can get it checked with your network team

Solution

I have already described high level areas where you need to look in in above section. Let’s discuss them further here.

Check TCP\IP settings

You should open SQL Server configuration manager and check whether TCP configuration is properly done or not. Make sure to review all settings in SQL Server Network configuration settings. You should also read below article about this settings which causes a network error.

• Fix: SQL Network Interfaces Error 28 – Server doesn’t support requested protocol

Review Network Packet Size

You should also review network packet size configuration in SQL Server. This could be one of the possible reason for this issue. Ideally we should not change the default value of this setting and keep it as it is until you have a specific requirement to change network packet size. Read below article to understand and learn network packet size in SQL Server and also step by step process about how to change the network packet size to your desired value.

• How to Change Network Packet Size Configuration in SQL Server

TCP Chimney Offload

This settings is very important if we have network related connectivity issue. TCP Chimney Offload is a networking technology that helps transfer the workload from the CPU to a network adapter during network data transfer. It can be enabled or disabled in the following two locations:

• The operating system
• The advanced properties page of the network adapter

TCP Chimney Offload will work only if it is enabled in both locations. By default, TCP Chimney Offload is disabled in both these locations. However, OEM installations may enable TCP Chimney Offload in the operating system, in the network adapter, or in both the operating system and the network adapter.

Validate Network related Driver Issues

You should speak to your network resource and Windows OS platform resource and validate all drivers at OS layer and network layer should be up to date and they should not have any issue. Make sure to update the drivers if you found any issue any of these layer.

I hope you can fix your issue by following above steps mentioned in this article. Comment us how you have fixed this issue, the semaphore timeout period has expired.) (Microsoft SQL Server, Error:121)

Related Articles

• SQL Server Error 40: A network-related or instance-specific error occurred while establishing a connection to SQL Server.
• Fix Error 1418: The server network address cannot be reached or does not exist.
• Fix: SQL Network Interfaces Error 28 – Server doesn’t support requested protocol
• SQL Server Native Client Error 50000: A network error occurred while attempting to read from the file

The post Fix SQL Server Error 121 – The Semaphore Timeout Period Has Expired appeared first on Techyaz.com.

• Mixed Mode ( Windows +SQL Server login )
• Windows Mode (Only Windows)

Mixed mode provides two ways to establish database connections. One is using SQL Server logins at SQL Server layer and another one is using Windows domain user authenticated using active directory and whose login is created and mapped on SQL Server instance.

Windows Mode has only one way to establish database connections and that is using windows domain accounts. We must map windows accounts on SQL Server first before making any database connections. This mode doesn’t provide access to SQL Server logins.

Read More to Grow:

• SQL Server Interview Questions & Answers on Indexes
• How to Prepare for a Job Interview?
• SQL Server Alwayson Interview Questions & Answers
• SQL Server Replication Interview Questions & Answers

Why Windows Authentication Mode is More Secure in SQL Server?

Windows mode is secure than Mixed mode authentication because mixed mode has SQL Server authentication which cannot use Kerberos security protocol. Windows account needs to be authenticated to domain active directory every time you establish a database connection. Also, Windows provides additional password policies that are not available for SQL Server logins and that is why Microsoft always recommends to use Windows authentication mode wherever it’s possible.

One more risk with Mixed mode is the encrypted SQL Server Authentication login password must be passed over the network at the time of the connection. Some applications that connect automatically will store the password at the client. These are additional attack points.

Change Authentication Mode in SQL Server

You can configure authentication mode in SQL Server during installing it to your system. SQL Server installation windows will allow you to choose any one of above given authentication modes. If you will choose mixed authentication mode then you need to provide sa password as per windows password policy. You can also change existing authentication mode setting to another one as per your business need.

Let’s assume you have installed SQL Server with Mixed authentication mode and now you have to change it to Windows Authentication mode. This section will explain step by step process to change SQL Server authentication mode.

We can set or change authentication mode in SQL Server either using SQL Server management studio or using T-SQL statements.

Using SQL Server Management Studio

1. Launch SQL Server Management Studio, connect to your target SQL Server instance.
2. In SQL Server Management Studio Object Explorer, right-click the server, and then click Properties.
3. On the Security page, under Server authentication, you can see both authentication modes. Select any as per your need and then click OK.
4. This change will require SQL Server service restart. A popup window will appear to ask you to restart the service when you will click at OK button in above step.
5. In Object Explorer, right-click your server, and then click Restart. If SQL Server Agent is running, it must also be restarted.

You have changed your authentication mode from Mixed mode to Windows using SQL Server Management Studio.

If you are changing authentication mode from Windows to Mixed mode then make sure to enable SQL Server login sa account. This account gets disabled during windows authentication mode to secure your SQL Server instance as sa is generic SQL Server login as it can be targeted by hackers to access your instance. Below are the steps to enable this account:

1. In Object Explorer, expand Security, expand Logins, right-click sa, and then click Properties.
2. On the General page, you might have to create and confirm a password for the sa login.
3. On the Status page, in the Login section, click Enabled, and then click OK.

Using T-SQL Statement

Microsoft has provided an extended stored procedure to chnage authenication mode in SQL Server using T-SQL statement. This extended stored procedure chnages windows registry entries so be careful while changing authentication mode in SQL Server using T-SQL statements. Make sure to take a backup of windows registry before executing this script.

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE',
N'Software\Microsoft\MSSQLServer\MSSQLServer',
N'LoginMode', REG_DWORD, 1
GO

Above command has again changed authenticating mode from mixed to windows.

If you are doing other way around then make sure to enable sa login as i suggested above. You can also use below T-SQL statement to enable sa account.

ALTER LOGIN sa ENABLE ;
GO
ALTER LOGIN sa WITH PASSWORD = 'STRONG-PASSWORD' ;
GO

Here, i have explained how to change SQL Server authentication mode from Windows to Mixed mode or vice versa. Please comment us if you have any feedback on this article.

Related Articles:

• Fix SQL Server Error 18456: Login failed for user ‘User_Name’.
• How to Change SQL Server Instance Name?
• Create a Logon Trigger to Restrict sysadmin logins to connect to SQL Server for given Time Interval
• Fix Error 18452: Login failed. The login is from an untrusted domain

The post How to Change Authentication Mode in SQL Server? appeared first on Techyaz.com.

SQLServer Error: 802, There is insufficient memory available in the buffer pool. [SQLSTATE 42000]

SQL Server Error 802 – Insufficient Memory Available in the Buffer Pool

The main reason behind getting SQL Server error 802 is your SQL Server instance is under memory pressure and there is not enough memory available to allocate further to buffer pool or buffer pool is restricted to not use memory beyond a certain limit. This might be because of various reasons as i have stated in below section. One of the very easy and straight forward approach to fix this error is to increase more memory to SQL Server system and modify max server memory in SQL Server accordingly.

Analysis & Solution

I would suggest to go deeper in this issue before taking any decision to allocate more memory to the system where SQL Server is running. There could be multiple temporary reasons as well which can cause SQL Server to generate below error log:

SQL Server Error: 802, There is insufficient memory available in the buffer pool. [SQLSTATE 42000]

Let’s discuss this issue further and ensure to not forget below points before taking any decisions.

Please comment us about your issue experience and let me know how you have fixed your issue.

Related Articles:

• How to Fix SQL Server Error 701: There is insufficient system memory to run this query
• Understanding Hybrid Buffer Pool in SQL Server
• SQL Server Interview Questions & Answers

The post Fix SQL Server Error 802: There is insufficient memory available in the buffer pool. appeared first on Techyaz.com.

We should be very careful while running any of the database maintenance activities on production databases. It becomes more crucial if your database size is very very big or some critical business application is using this database. Yesterday i had similar experience in one of our SAP system. Application team had reported performance issue while accessing one of the SAP system. DBAs were involved and identified a long running query that was causing the performance issue. This long running query was executing update statistics SQL Server operation on one of the biggest table in the database. This activity took very long time around 12 hours and never completed. Finally team has killed this transaction as advised by SAP support to improve the performance.

Understanding Update Statistics in SQL Server

SQL Server uses statistics to generate fastest query plan for any transaction so we should ensure all statistics must be up to date to get better query performance. As per MSDN “Updating statistics ensures that queries compile with up-to-date statistics. However, updating statistics causes queries to recompile. We recommend not updating statistics too frequently because there is a performance tradeoff between improving query plans and the time it takes to recompile queries. “

Here, first i will explain one of my issue as case study and then will give you SQL update statistics best practices. There are multiple things that can lead to longer duration of this execution, so first we should understand the issue before reaching on any conclusion.

After looking into SQL Server transactions, we found that SQL Server update statistics was being executed with FULLSCAN option. This was a potential reason behind taking it for longer duration. Avoid running update statistics with FULLSCAN option while running it on very big tables or databases because it scans each and every record in the table that will degrade the system performance and took more time to complete. Although, you should always rethink before making a decision to run update statistics on your database if auto update statistics has been set to ON. As it was SAP ECC database so we checked the SAP documentation as well and SAP also suggests to not run it regularly if auto update statistics is set to ON. This is SQL Server auto update statistics best practices for very large databases.

In some cases, if you still have to run the update stats then always Use it without mentioning FULLSCAN parameter or use sp_updatestats stored procedure. If you still need to run WITH FULLSCAN then do not run the UPDATE STATISTICS SQL Server command against the entire table. Identify the column or index statistic that needs the special treatment, and only update that one with FULLSCAN.

Sometimes, SQL Server update statistics command may take very long time even after following above measures. This could be because of the bug reported in attached link. This has been fixed in below CU updates. Check your SQL Server version and apply them to fix this issue if applicable.

• Cumulative Update 2 for SQL Server 2019
• Cumulative Update 18 for SQL Server 2017
• Cumulative Update 11 for SQL Server 2016 SP2

SQL Server Update Statistics Best Practices

Below is the list of best practices i have mentioned to be considered while running update statistics in SQL Server. Have a look at them.

1. Running Update Statistics on very big tables or database can increase huge IO pressure on your disk subsystem. SQL Server has very good feature to keep running it in real time by setting value auto update statistics to ON. If auto update statistics is set to ON then it is strongly recommended to not run it regularly on any databases. We can run it only on those tables where this setting is set to OFF.
2. In some cases, if you still have to run the update stats then always Use it without mentioning FULLSCAN parameter or use sp_updatestats stored procedure. If you still need to run WITH FULLSCAN then Do not run the UPDATE STATISTICS command against the entire table. Identify the column or index statistic that needs the special treatment, and only update that one with FULLSCAN.
3. Always run such database maintenance activities during maintenance windows. It is not recommended to run during business hours.
4. If you are facing performance issue during update stats execution then you should check the possibilities of potential bug reported in attached link.
5. Never run Adhoc and manual Update stats on any of the very big tables if Auto Update Statistics is set to ON because Update stats is very costly operations in terms of heavy IO activities. It does acquire schema-stability locks so it can potentially be blocked by a DDL operation (like ALTER TABLE).
6. One way to find out whether you should run update stats or not is to check if your statistics are stale in the execution plans or not. If estimated rows greatly differ from your actual rows returned in execution plan then that is a good indication of potential update stats candidate.
7. Ask Migration team (In case recently migrated) whether they have executed rebuild index or update stats after migrating data to SQL Server as part of post upgrade activity? Ideally it is recommended to run update stats after massive data load because auto update stats does not automatically update all records.
8. If you’ve got tables with millions of rows, and you’ve found that statistics aren’t updating fast enough, you can consider:
   • Turning on Trace Flag 2371 to make auto-update statistics run more frequently on tables with large amounts of rows.
   • Using a third party script to handle statistics maintenance along with your index maintenance
9. One way to find out if your statistics are stale is to look at the execution plans and if you estimated rows greatly differ from your actual rows returned then that is a good indication that the interval needs to be upped. If you want to do update Statistics manually you should first know When Statistics are updated automatically.
10. If the SQL Server query optimizer requires statistics for a particular column in a table that has undergone substantial update activity since the last time the statistics were created or updated, SQL Server automatically updates the statistics by sampling the column values (by using auto update statistics). 

Update Statistics on AlwaysON Secondary Replica

Temporary statistics are an improvement added in SQL Server 2012 for read-only databases. When a database is read-only, queries can’t create statistics in the database– because those require writes. As of SQL Server 2012, temporary statistics can be created in tempdb to help optimization of queries.

This is incredibly useful for:

• Readable secondaries in an AlwaysOn Availability Group
• Readable logshipping secondary databases
• A point in time database snapshot which is queried (whether against a database mirror or live database)
• Any other read-only database that has queries run against it

Prior to SQL Server 2012, if you use logshipping for reporting and the same workload does not run against the log shipping publisher, consider manually creating column level statistics. (Or upgrading SQL Server.)

Read More:

• Understanding Database Autogrowth in SQL Server
• Understanding Database Shrink Operation
• SQL Server AlwaysON Interview Questions & Answers

The post SQL Server Update Statistics Best Practices appeared first on Techyaz.com.

Before going ahead, you might be thinking what is Persistent Memory devices and how it is related to SQL Server. Let me first explain about persistent memory.

What is Persistent Memory?

Persistent memory generally termed as PMEM, is a solid-state high performance byte-addressable memory device that resides on the memory bus. It has many benefits over other storage devices.

The main advantages of persistent memory include: 

• It provides fast data access near real-time without any latency than flash SSDs for large data sets as well.
• PMEM increases throughput more than flash storage.
• Biggest benefit is its cost. It’s cheaper than DRAM. 
• PMEM is cacheable. This is a huge advantage over PCIe interconnect, which cannot be cached in the CPU.
• It retains Data in memory after power interruption or shut off. 

Persistent memory can be used in a variety of ways to deliver lower latency for applications where you need fast data access with enormous amount of data such as IoT applications, Cyber threat analysis, financial trading etc.

What is Hybrid Buffer Pool?

In a traditional system, SQL Server caches data pages in the buffer pool. With Hybrid Buffer Pool, SQL Server skips performing a copy of the page into the DRAM-based portion of the buffer pool, and instead references the page directly on the database file that lives on a PMEM device. Access to data files in PMEM for Hybrid Buffer Pool is performed using memory-mapped I/O, also known as enlightenment. This brings performance benefits from avoiding a copy of the page to DRAM, and from the avoidance of the I/O stack of the operating system to access the page on persistent storage.

Only clean pages can be referenced directly on a PMEM device. When a page becomes dirty it is kept in DRAM, and then eventually written back to the PMEM device.

This feature will be available in both Windows and Linux version of SQL Server 2019.

How to Enable Hybrid Buffer Pool?

We can enable Hybrid Buffer Pool for SQL Server instance by enabling trace flag during SQL Server startup. As of now, the current process is, we must enable the startup trace flag 809 in order to use Hybrid Buffer Pool.

Microsoft suggests a best practice to keep in mind while enabling
Hybrid Buffer Pool in SQL Server. We should use largest allocation size available for NTFS and ensure the device has been enabled for DAX (DirectAccess) while formatting the PMEM device on Windows.

I hope you liked this article. Please write your comments if you have any questions.

Read More:

• SQL Server 2017 New Features
• New T-SQL Functions introduced in SQL Server 2017
• SQL Server DBA Interview Questions & Answers

The post Understanding Hybrid Buffer Pool in SQL Server appeared first on Techyaz.com.

VIEW SERVER STATE Permission

This is high level server-level privilege which must not be granted to everybody. Only administrators must have privilege to use view server state permission but we can assign this permission to some users who want to see server level state of your SQL Server instance. Once you will grant this access to any login, he can see result of all DMVs.

Solution – ( Microsoft SQL Server, Error 300 )

We got SQL Server error 300 ( VIEW SERVER STATE permission was denied ) because the login you are using to execute the script doesn’t have this permission. To fix this issue we will grant view server state permission to the login name. This section will explain how to grant view server state permission to a login.

Grant VIEW SERVER STATE Permission

We can assign this permission either using GUI in SQL Server Management Studio or we can simply execute a T-SQL command to get this done. I will explain both ways to assign this permission.

Using GUI in SQL Server Management Studio

Follow below steps to do it using GUI.

1. Launch SQL Server Management Studio.
2. Connect to the SQL Server Instance.
3. Navigate to Security folder then expand Logins
4. Right Click at your login name and choose Properties
5. Click at Securables tab from left side pane.
6. In the bottom pane, scroll to the bottom and click at Grant option for View Server State value.
7. Now click on apply to close the window. You can now ask your user to test the script again. This time it will work.

Using T-SQL statement in SQL Server Management Studio

1. Launch SQL Server Management Studio. Connect to the SQL Server Instance.
2. Open New Query window
3. Run below T-SQL statement

USE master
GO
GRANT VIEW SERVER STATE TO "LoginName"

Once you execute above command, you will have view server state permission on your login name. You can resolve SQL Server error 300 VIEW SERVER STATE permission was denied on object ‘server’, database ‘master issue by following above steps given in this article.

Revoke VIEW SERVER STATE Permission

If you have identified anyone who must not have this permission then you can go ahead and revoke his access post getting proper approvals. Make sure that identified login does not have any business justification before revoking his access. Once you have decided to go ahead to remove view server state permission then you should run below T-SQL statement to get this done. Below steps will tell you how to revoke view server state permission of any login.

USE master

REVOKE VIEW SERVER STATE TO “LoginName”

GO

View SERVER STATE permission has been revoked for identified login post successful execution of above statement.

I hope you like this article. Please follow our facebook page and Twitter handle to get latest updates.

Read More:

• SQL Server AlwaysON Interview Questions & Answers
• SQL Server DBA Interview Questions & Answers
• Understanding Enhanced Database Failover in Always on Availability Group
• SQL Server Replication Interview Questions & Answers

The post Fix:VIEW SERVER STATE permission was denied on object ‘server’, database ‘master’ appeared first on Techyaz.com.

Msg 5184, Level 16, State 2, Line 1
Cannot use file ‘I:\Path\Techyaz.mdf’ for clustered server.
Only formatted files on which the cluster resource of the server has a dependency can be used. Either the disk resource containing the file is not present in the cluster group or the cluster resource of the Sql Server does not have a dependency on it.

Msg 1802, Level 16, State 1, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

While troubleshooting this error we came to know that the storage or LUN on which we have placed the database files are not added to cluster group. It means disk is not visible in failover cluster manager.

Solution – Error 5184

We performed below steps to fix this issue.

1. Added the storage on which databases files are placed as shared storage in the failover cluster manager.
2. Launch SQL Server properties window in Failover Cluster Manager.
3. Added all newly added disks in Dependencies tab.
4. Attached the database again.

Here i will explain above steps in detail with screenshots.

• We were attaching a database using T-SQL statement on one of the SQL Server cluster instance. While executing the command we get error 5184. Error details are given in below screenshot.

• As error suggests that “Either the disk resource containing the file is not present in the cluster group” so I checked cluster group for the disk and found that database files storage was not showing in failover cluster manager.
• Next step was to add these storage disks to the cluster group. Launch failover cluster manager. Click at Roles tab from left side pane. You can see SQL Server as role in right side pane. Right click at the SQL Server role and click at “Add Storage” option. You can see this in below screenshot.

• Once you will click at “Add Storage” option you will get below window to add the identified disks to cluster group. You can see I have selected all required disks in below screenshot. You can choose your disks where your database files are placed.

• Once you click at OK button post selecting all respective check boxes in above step, you will see all your storage disks in failover cluster manager under storage tab.
• Now again click at the SQL Server role and then go to “Resources” tab from down side pane where you can see SQL Server and all resources that are aligned for the SQL Server role. Here, right click at SQL Server and click at Properties tab as shown in below screenshot.

• Once you get SQL Server properties windows in failover cluster manager, next you should click at dependencies tab. Here, you need to insert one row for each disk system that you have added in above steps. Once you will insert dependencies for all newly added disks then it will look like below screenshot. Now click at OK button to apply this change.

• Now again go to SQL Server query window and run the T-SQL command to  attach the database. This time you will successfully attach the database to the clustered SQL Server instance.

Let me know if this article helped you to fix your issue. You can follow our facebook page and Twitter handle to get latest updates.

Read More:

• Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group
• How to Change Failover Mode of Availability Replica in AOAG?
• How to Prepare for a Job Interview?
• SQL Server DBA Interview Questions & Answers

The post SQL Server Error 5184: Cannot use file ‘I:\Path\Techyaz.mdf’ for clustered server appeared first on Techyaz.com.