SQLServerCentral » All Posts https://www.sqlservercentral.com/forums/feed Wed, 18 Mar 2026 22:12:58 +0000 https://bbpress.org/?v=2.6.12 en-GB https://www.sqlservercentral.com/forums/topic/vs-code-unresolved-references#post-4752030 <![CDATA[VS Code, Unresolved References.]]> https://www.sqlservercentral.com/forums/topic/vs-code-unresolved-references#post-4752030 Wed, 18 Mar 2026 21:43:16 +0000 mjdemaris Hi all,

I just started using VS Code to work with DB projects.  I have a work-in-progress DB, meaning some of the objects are broken.  But, for those that are not broken, when I run

dotnet build

I get many unresolved reference errors that have no problem existing on the server or in SSMS.  The first few objects on the list are views, which almost all use table aliases.  Looking through the scripts, all use Schema.Table references.  A few tables do not have red underlines, but most do.  Some of these views also use CTEs, not sure if that makes any difference, though.

I created this project as new, then added a database reference directly to our Server.DB.  I would like to understand why this happens and what I can do to mitigate or prevent it.  I would show some examples, but that's forbidden.

I also noticed in the msbuild.log file things like this:

 The "DefaultSdkResolver" resolver attempted to resolve the SDK "Microsoft.Build.Sql/2.1.0".
                   Warnings: null
                   Errors: MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.Build.Sql" because directory "C:\Program Files\dotnet\sdk\8.0.419\Sdks\Microsoft.Build.Sql\Sdk" did not exist.


The "Microsoft.DotNet.MSBuildWorkloadSdkResolver" resolver attempted to resolve the SDK "Microsoft.Build.Sql/2.1.0".  Warnings: null

Errors: MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.SDK.WorkloadAutoImportPropsLocator" because directory "C:\Program Files\dotnet\sdk\8.0.419\Sdks\Microsoft.NET.SDK.WorkloadAutoImportPropsLocator\Sdk" did not exist.
                   The SDK "Microsoft.NET.SDK.WorkloadAutoImportPropsLocator" was successfully resolved by the "Microsoft.DotNet.MSBuildWorkloadSdkResolver" resolver to location "null" and version "null".

I am not quite sure how to fix those, either.  Could they be contributing to the unresolved SQL reference errors?

Advice?

Thanks!

]]> https://www.sqlservercentral.com/forums/topic/windows-logins-for-users-migrated-from-domaina-to-domainb#post-4752006 <![CDATA[Reply To: Windows logins for users migrated from DomainA to DomainB]]> https://www.sqlservercentral.com/forums/topic/windows-logins-for-users-migrated-from-domaina-to-domainb#post-4752006 Wed, 18 Mar 2026 20:41:51 +0000 a.koopman Hi Johan,

Thanks for the answer, yes this indeed happened.  I only wonder: How can I determine if "DomainA\JohnDoe" is the same as "DomainB\JohnDoe" (migrated) versus "DomainA\PeggySue" and "DomainB\PeggySue" (not migrated)?

Thanks,

Adri

]]> https://www.sqlservercentral.com/forums/topic/changing-data-types-2#post-4751985 <![CDATA[Reply To: Changing Data Types]]> https://www.sqlservercentral.com/forums/topic/changing-data-types-2#post-4751985 Wed, 18 Mar 2026 19:41:43 +0000 m60freeman I've seen this most often in Microsoft code-first projects where either no data modelling was done before development started, or no DBA reviewed the design before the first version of the application was deployed to production.

At that point, management often decides it is too risky or involves too much development work to change the data type, unless the performance impact of having the improper data type is sufficiently painful.

]]> https://www.sqlservercentral.com/forums/topic/dynamic-unpivot#post-4751967 <![CDATA[Reply To: Dynamic Unpivot]]> https://www.sqlservercentral.com/forums/topic/dynamic-unpivot#post-4751967 Wed, 18 Mar 2026 19:23:30 +0000 pietlinden just wondering. There's not really a way to achieve this without dynamic SQL, right? I don't think so because you don't know beforehand how many of the repeating groups there are (the columns in the CROSS APPLY).

]]> https://www.sqlservercentral.com/forums/topic/4739388#post-4739388 <![CDATA[Fun with JSON II]]> https://www.sqlservercentral.com/forums/topic/4739388#post-4739388 Wed, 18 Mar 2026 00:00:50 +0000 Steve Jones - SSC Editor Comments posted to this topic are about the item Fun with JSON II

]]> https://www.sqlservercentral.com/forums/topic/changing-data-types-2#post-4745165 <![CDATA[Changing Data Types]]> https://www.sqlservercentral.com/forums/topic/changing-data-types-2#post-4745165 Wed, 18 Mar 2026 00:00:42 +0000 Steve Jones - SSC Editor Comments posted to this topic are about the item Changing Data Types

]]> https://www.sqlservercentral.com/forums/topic/answering-questions-on-dropped-columns#post-4743985 <![CDATA[Answering Questions On Dropped Columns]]> https://www.sqlservercentral.com/forums/topic/answering-questions-on-dropped-columns#post-4743985 Wed, 18 Mar 2026 00:00:00 +0000 Cláudio Silva Comments posted to this topic are about the item Answering Questions On Dropped Columns

]]> https://www.sqlservercentral.com/forums/topic/xact_abort-being-set-to-on-by-web-services#post-4751088 <![CDATA[Reply To: XACT_ABORT being set to ON by web services]]> https://www.sqlservercentral.com/forums/topic/xact_abort-being-set-to-on-by-web-services#post-4751088 Tue, 17 Mar 2026 14:02:34 +0000 Mr. Brian Gale If it is just 1 stored procedure causing it and not everything coming from that system, I would suspect that the code is different between the 2 systems and that in the code, after opening the connection but before running the stored procedure, it is setting XACT_ABORT to ON. If it is all stored procedures called by that web app, then I'd say it is more likely to be driver related.

My opinion - the workaround gets you into a functional state, but it is a temporary fix. I would spin up a test environment and try to replicate the issue. That'll make it easier to debug without causing business impact.

The above is all just my opinion on what you should do. 
As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

]]> https://www.sqlservercentral.com/forums/topic/xact_abort-being-set-to-on-by-web-services#post-4751026 <![CDATA[Reply To: XACT_ABORT being set to ON by web services]]> https://www.sqlservercentral.com/forums/topic/xact_abort-being-set-to-on-by-web-services#post-4751026 Tue, 17 Mar 2026 12:19:04 +0000 zoggling We ran several extended event sessions to try to pin down where XACT_ABORT was being set, but we have been unable to identify where this is coming from. Running a job every few seconds to capture the options for each connected session to a database table showed that XACT_ABORT was set to OFF for all sessions, so it has proved somewhat tricky to pin down.

We have had to put a workaround in place, to explicitly SET XACT_ABORT OFF; at the top of the problematic stored procedure, and it has resolved the issue. So it is definitely related to this.

]]> https://www.sqlservercentral.com/forums/topic/restoring-on-top-ii#post-4749780 <![CDATA[Automated reply to Restoring On Top II]]> https://www.sqlservercentral.com/forums/topic/restoring-on-top-ii#post-4749780 Tue, 17 Mar 2026 00:10:02 +0000 Site Owners Thanks for posting your issue and hopefully someone will answer soon.

This is an automated bump to increase visibility of your question.

]]>