Insert & Update both implemented wrong semantically
Insert means to introduce something, adding/entering something new Update means to change something, change and existing value. Semantically and logically speaking, Insert should only be used to enter data into an empty or partially empty record/table. Update should only be used to change existing values within a record/table. Using a 5 column table as an example where column 1 is an email address Example1 INSERT INTO table (Column1,Column2,Column3) VALUES (value1,value2,value3) Or Example2 INSERT INTO table VALUES (value1,value2,value3,value4,value5) With example 1, 2 columns are left empty Semantically, insert should be used to populate columns for the first time INSERT INTO table (column4, column5) VALUES (value4,value5) where column1 = "EmailAddress" Then for example, UPDATE table SET COLUMN2 = "newValue" WHERE COLUMN1 = "EmailAddress" Updating (setting) an empty column should cause an error, cannot update an empty column SQL, a great idea, pity its implementation is tainted by bad design. SQL works, but its design/implementation of Insert & Update is semantically wrong. IMO As the saying goes, if it isn't broken, don't fix it. Who cares about semantics or logic.SQL Server does not reduce the size of MDF and LDF
I am a SQL Server 2017 user, I deleted a table that had too many records, but after the delete process, the size of the MDF and LDF files did not decrease, but increased. I have shrunk the file but the file size remains the same. What should I do to change the file size?
How can I optimize this query for better performance
Hi , I have this query and it is taking a long time. If there are more than 10k rows, it takes more than 5 minutes. Is there another way to speed up the process? SELECT ROW_NUMBER() OVER (ORDER BY CreationDate DESC) AS RowId, Id [Id], transactionsId [TransactionsId], amount [Amount], AccountId [AccountId], dbo.Account_FirstBalance(CreationDate, AccountId, 161, CompanyId) [FirstBalance] FROM p_Ledger WHERE CreationDate >= '2024-11-01' AND CreationDate <= '2025-02-11' AND CompanyId = 117 AND branchId = 161 ALTER FUNCTION [dbo].[Account_FirstBalance]( @TransactionsDate DATETIME, @AccountId BIGINT, @BranchId INT, @CompanyId BIGINT ) RETURNS FLOAT AS BEGIN DECLARE @credit FLOAT; SELECT @credit = SUM(CASE WHEN T.transactionStatusId = 1 THEN T.amount ELSE -T.amount END) FROM dbo.Transactions T WHERE T.Approval = 1 AND T.CompanyId = @CompanyId AND T.AccountsId = @AccountId AND T.IsDeleted = 0 AND T.transactionsDate < @TransactionsDate AND (@BranchId = 0 OR T.branchId = @BranchId); RETURN ROUND(COALESCE(@credit, 0), 2); END;
What are the best practices for managing and optimizing a SQL table that contains 10 million records
I have a table that currently holds 10 million records, and it continues to grow daily. As the dataset expands, I'm encountering significant challenges in retrieving data efficiently and generating reports. The increasing volume of data is causing performance bottlenecks, leading to slow query execution times and delays in report generation. To address these issues, I need to implement strategies for optimizing data retrieval and managing the growing dataset effectively and to ensure that the system remains responsive and capable of handling the increasing data load.
Need help in restoring table using large .sql data file(4GB)
We have run into a situation where we need to restore the data into a SQL table. We have taken backup of data only using MS SQL Server and the .sql file size is 4 GB. Since we are unable to open this file in SQL server, we are using sqlcmd to execute this file but after restoring 140K records it is throwing some syntax error (Unclosed quotation mark after the character strig 'abc_121223354565 and incorrect syntax near 'abc_121223354565 ). The .sql file has total 240K records in it. Questions: 1. When the backup was provided by SQL server only, why it is throwing syntax error? 2. How to open this large file to fix the syntax error? if option 2 is not possible, how do we split the large file into smaller chunks so we can identify the exact place where the issue is? Thanks, Srikanth
Understanding the Differences Between SWITCHOFFSET and AT TIME ZONE in SQL Server
When working with date and time data in SQL Server, handling different time zones can be a critical aspect, especially for applications with a global user base. SQL Server provides two functions that can be used to handle time zone conversions: SWITCHOFFSET and AT TIME ZONE. Although they might seem similar at first glance, they have distinct differences in functionality and use cases. This article aims to elucidate these differences and help you decide which one to use based on your requirements. SWITCHOFFSET The SWITCHOFFSET function is used to change the time zone offset of a datetimeoffset value without changing the actual point in time that the value represents. Essentially, it shifts the time by the specified offset. Syntax SWITCHOFFSET (DATETIMEOFFSET, time_zone_offset) DATETIMEOFFSET: The date and time value with the time zone offset you want to change. time_zone_offset: The new time zone offset, in the format +HH:MM or -HH:MM. Example DECLARE @dt datetimeoffset = '2023-12-31 23:09:14.4600000 +01:00'; SELECT SWITCHOFFSET(@dt, '+00:00') AS UtcTime; In this example, SWITCHOFFSET converts the time to UTC by applying the +00:00 offset. AT TIME ZONE The AT TIME ZONE function is more advanced and versatile compared to SWITCHOFFSET. It converts a datetime or datetime2 value to a datetimeoffset value by applying the time zone conversion rules of the specified time zone. It can also be used to convert a datetimeoffset value to another time zone. Syntax DATETIME [AT TIME ZONE time_zone] DATETIME: The date and time value to be converted. time_zone: The target time zone name. Example DECLARE @dt datetimeoffset = '2023-12-31 23:09:14.4600000 +01:00'; SELECT @dt AT TIME ZONE 'UTC' AS UtcTime; In this example, AT TIME ZONE converts the datetimeoffset to the UTC time zone. Key Differences Functionality: SWITCHOFFSET only adjusts the time by the specified offset without considering daylight saving rules or historical time zone changes. AT TIME ZONE considers the full time zone conversion rules, including daylight saving changes, making it more accurate for real-world applications. Input and Output: SWITCHOFFSET works with datetimeoffset values and outputs a datetimeoffset value. AT TIME ZONE works with datetime, datetime2, and datetimeoffset values and outputs a datetimeoffset value. Use Cases: Use SWITCHOFFSET when you need a quick offset change without needing full time zone awareness. Use AT TIME ZONE when you need precise and accurate time zone conversions, especially when dealing with historical data and daylight saving time. Performance Considerations When working with large datasets, performance is a crucial aspect to consider. SWITCHOFFSET: Generally faster for simple offset changes as it performs a straightforward arithmetic operation. AT TIME ZONE: May incur additional overhead due to the complexity of applying time zone rules, but it provides accurate results for real-world time zone conversions. Example with a Large Dataset Suppose you have a Users table with 200,000 records, each having a CreatedDate column with datetimeoffset values in various time zones. Converting these to UTC using both methods can illustrate performance differences. -- Using SWITCHOFFSET SELECT COUNT(*) FROM Users WHERE CAST(SWITCHOFFSET(CreatedDate, '+00:00') AS date) = '2024-01-01'; -- Using AT TIME ZONE SELECT COUNT(*) FROM Users WHERE CONVERT(date, CreatedDate AT TIME ZONE 'UTC') = '2024-01-01'; In scenarios like this, benchmarking both methods on your specific dataset and SQL Server environment is advisable to understand the performance implications fully. CPU Times vs Total Duration Let's analyze the efficiency of the two alternatives (SWITCHOFFSET and AT TIME ZONE) when working with a table containing 200,000 records with different time zones in the datetimeoffset field named CreatedDate. Example Table Preparation First, create an example table Users with a CreatedDate field of type datetimeoffset and insert 200,000 records with different time zones. sql -- Create the example table CREATE TABLE Users ( UserID INT IDENTITY(1,1) PRIMARY KEY, CreatedDate DATETIMEOFFSET ); -- Insert 200,000 records with different time zones DECLARE @i INT = 1; WHILE @i <= 200000 BEGIN INSERT INTO Users (CreatedDate) VALUES (DATEADD(MINUTE, @i, SWITCHOFFSET(SYSDATETIMEOFFSET(), CONCAT('+', RIGHT('0' + CAST((@i % 24) AS VARCHAR(2)), 2), ':00')))); SET @i = @i + 1; END; Measuring Efficiency Now, measure the two alternatives for converting the CreatedDate field to UTC and then projecting it as date. Option 1: SWITCHOFFSET sql SET STATISTICS TIME ON; SELECT CAST(SWITCHOFFSET(CreatedDate, '+00:00') AS date) AS UTCDate FROM Users; SET STATISTICS TIME OFF; Option 2: AT TIME ZONE sql SET STATISTICS TIME ON; SELECT CONVERT(date, CreatedDate AT TIME ZONE 'UTC') AS UTCDate FROM Users; SET STATISTICS TIME OFF; Execution Plan and Timing Analysis After running both queries, compare the CPU times and the total duration reported by SET STATISTICS TIME ON to evaluate efficiency. Possible Efficiency Differences SWITCHOFFSET: SWITCHOFFSET is likely more efficient in this scenario because it performs a single operation to adjust the time zone and then projects it as date. This operation is done in a single step, which can reduce overhead. AT TIME ZONE: AT TIME ZONE might introduce a slight overhead because it first changes the time zone and then converts it to date. However, AT TIME ZONE is clearer and can handle multiple time zones more explicitly. Recommendation Although the real efficiency can depend on the specific environment and the detailed execution plan, generally, SWITCHOFFSET is expected to be more efficient for large datasets when only adjusting the time zone and projecting the date is required. Code for Testing in SQL Server sql -- Option 1: SWITCHOFFSET SET STATISTICS TIME ON; SELECT CAST(SWITCHOFFSET(CreatedDate, '+00:00') AS date) AS UTCDate FROM Users; SET STATISTICS TIME OFF; -- Option 2: AT TIME ZONE SET STATISTICS TIME ON; SELECT CONVERT(date, CreatedDate AT TIME ZONE 'UTC') AS UTCDate FROM Users; SET STATISTICS TIME OFF; Comparing Results CPU Times: Compare the CPU times reported by both queries. Total Duration: Compare the total duration of execution of both queries. Evaluating the results from the time statistics will help determine which option is more efficient for your specific case. Additional Considerations Indexes: Ensure that the CreatedDate column is indexed if large volumes of data are expected to be read. Parallelism: SQL Server can handle the query in parallel to improve performance, but parallelism settings might affect the results. Real-World Workload: Conduct tests in an environment as close to production as possible to obtain more accurate results. Conclusion Choosing between SWITCHOFFSET and AT TIME ZONE depends on your specific needs: Use SWITCHOFFSET for simple, quick offset changes where historical accuracy and daylight saving adjustments are not critical. Use AT TIME ZONE for comprehensive and accurate time zone conversions, especially in applications dealing with users across multiple time zones and needing historical accuracy. Understanding these differences will help you make informed decisions in your SQL Server applications, ensuring both performance and accuracy in your date and time data handling.
How to connect an Access database to an Always-On Listener?
I follow this instruction for SQL Server and hope it is applicable to the listener https://support.microsoft.com/en-us/office/import-or-link-to-data-in-an-sql-server-database-a5a3b4eb-57b9-45a0-b732-77bc6089b84e I go to EXTERNAL DATA -> NEW DATA SOURCE -> FROM DATABASE -> FROM SQL SERVER -> LINK TO THE DATA SOURCE BY CREATING A LINKED TABLE -> MACHINE DATA SOURCE -> NEW ->SQL SERVER -> then I enter a name and as server the DNS name of my listener, that is listener in my case. -> then I choose SQL server authentication method as authentication method and enter password and user -> then two errors come: SQLState: 0100 SQL Server error: 53 SQLState: 08001 ConnectionOpen (Connect()) SQL Server error: 17 SQL Server does not exist or access is denied. The ping to the listener also exists. With a SQL Server my steps work. What am I doing wrong?Need Help with speed up update query
Hello Everyone I have this update query to update Generaljournals table from DIMENSIONATTRIBUTELEVELVALUEVIEW Generaljournals table has more than 20M rows DIMENSIONATTRIBUTELEVELVALUEVIEW 7M rows when I run the query it takes around 1hour how can I make the update be better and take less time ? update GENERALJOURNALS set branches = a.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW a where a.PARTITION = GENERALJOURNALS.PARTITION and a.VALUECOMBINATIONRECID = GENERALJOURNALS.LEDGERDIMENSION and a.DIMENSIONATTRIBUTE = '5637145326' and GENERALJOURNALS.branches = '' update GENERALJOURNALS set mangment = a.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW a where a.PARTITION = GENERALJOURNALS.PARTITION and a.VALUECOMBINATIONRECID = GENERALJOURNALS.LEDGERDIMENSION and a.DIMENSIONATTRIBUTE = '5637145333' and GENERALJOURNALS.mangment='' update GENERALJOURNALS set MainSector = a.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW a where a.PARTITION = GENERALJOURNALS.PARTITION and a.VALUECOMBINATIONRECID = GENERALJOURNALS.LEDGERDIMENSION and a.DIMENSIONATTRIBUTE = '5637145327' and GENERALJOURNALS.MainSector = '' update GENERALJOURNALS set SecondSector = a.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW a where a.PARTITION = GENERALJOURNALS.PARTITION and a.VALUECOMBINATIONRECID = GENERALJOURNALS.LEDGERDIMENSION and a.DIMENSIONATTRIBUTE = '5637145328' and GENERALJOURNALS.SecondSector = '' update GENERALJOURNALS set ThirdSection = a.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW a where a.PARTITION = GENERALJOURNALS.PARTITION and a.VALUECOMBINATIONRECID = GENERALJOURNALS.LEDGERDIMENSION and a.DIMENSIONATTRIBUTE = '5637145329' and GENERALJOURNALS.ThirdSection = '' update GENERALJOURNALS set Vendor = a.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW a where a.PARTITION = GENERALJOURNALS.PARTITION and a.VALUECOMBINATIONRECID = GENERALJOURNALS.LEDGERDIMENSION and a.DIMENSIONATTRIBUTE = '5637145334' and GENERALJOURNALS.Vendor = ''
