i need you guys help. I added a SQL Server Database to my asp.net project. However when i try to create a new table in the database, the error "An incompatible SQL Server Version was detected" come up.
I tried looking up online for solution and install the SSDT for it however it still do not work. I checked under "Extension and Updates", Microsoft SQL Server Update is not stated there too so I don't know what is going on... please help me experts. Currently using visual studio 2015 community version.
Try this--though it is hard to explain, and the actual details/location of information may vary depending on version, edition, installation, language, phase of the moon, etc. etc.
No guarantee this is your problem, but it--or something similar--is possible.
Open the Properties for the database project
There should be a set of tabs or pages. One of these is "Project Settings"
There should be a dropdown labeled "Target platform
Set this to the version of SQL you have installed/are trying to support.
Attempting to attach a sample screen shot, below
Walking through that... I suspect this might not actually be your problem. Thing is, there are settings and switches similar to this in many places, and one of them is probably what you are looking for. Good luck!
Related
The latest changelog (18.0 Preview 7) of SQL Server Management Studio announced, that the T-SQL Debugger is deprecated.
What are the alternatives for the future? Can someone understand this decision? I fear that removing a fundamental development tool like this will effect many developers.
You just need to download the Visual Studio 2019 Community.
Once you've done that, create a new project and open the SQL Server Object Explorer (CTRL + S).
You will be able to see your list of SQL Server databases, just as you did in SQL Server Management Studio.
Finally, left click one database and select "New Query". Now you can debug T-SQL just as you did in SSMS.
But the debugger does not work with Azure SQL
It seems that Microsoft may have temporarily moved the branch of debugging
from
SSMS18 to SQLServer Data Tools (SSDT).
According to developers of DBA Stackexchange community, there is
another alternative way to debugging, since Debugger is deprecated in
SSMS18.
Here is the link that shows how to achieve debugging : How to add the Debug
button to
SSMS v18?
ALTERNATIVE: ??
Just when I thought there would be no solution to this coming out any time soon, to my surprise there might be one.
There is a tool that I've come across lately while dabbling into this
debugger thing in SSMS18 out of curiosity, which goes by the name SQL Complete.
The company Devart apparently specializes in Database products and provides toolsplug-ins for various major databases.
Here is a small video of them briefing about the debugging feature in their tool SQL Debugger in the new version of dbForge SQL Complete
It's available on Visual Studio Marketplace.
#dens is correct by going to visual studio community edition however this is half of the answer as table variable values cannot be inspected and have the placeholder as (table); This is due to Microsoft not finishing this portion of the debugger. Currently, you can only see primitive data types outputted within the Locals Tab.
The work around to see table variables when they are deleted, updated or inserted into is to utilize the output keyword with each query to output the inserted or deleted elements. Now when you step through you will see the primitive variables within the debugger logger tab called "Locals" and the table variables within the Results or T-SQL tab as you step through. unfortunately the variable name will not be next to the output however as you step through, its pretty clear which table output belongs to which variable
Furthermore, if you are debugging a stored procedure on a SQL database not on your local database, i recommend backing up a local version of the database with the developer edition of SQL server since attaching a debugger to the query will get blocked by the firewall. Then you will require sysadmin privileges and open ports which may work however it did not work within my workplace. we tried even dropping the entire firewall and nothing but good luck.
I have an issue setting up merge replication on a SQL 2012 instance.
The push of the snapshot to the subscriber is failing and the reason I discovered was because there is a SP that uses a Full Text Index that has not been generated on a table.
A lot of searching about revealed that there is a property that is false by default that defines if a full text index should be copied.
I thought I had found the solution, set this property to true and triggered a new snapshot, however, the same issue was still encountered and when I went back to check the property the copy full text index property was set to false again??
I have tried a few times in the hope it was just me forgetting to save or something, from what I can see, the property stays at true until the snapshot is rerun, after that the property is back at false again, I am wondering if I have come up against a bug in SQL server, however, a google does not appear to indicate this is true.
I have tried deleting and recreating the publication. I have also tried disabling the distributor and publisher in order to force a fresh distribution DB to be created, thinking that maybe there is a corruption somewhere.
Both servers are running SQL Server 2012 on Windows Server 2012R2
Does anyone have any fresh ideas?
I had similar problems with full text catalogs/search setup when using old SQL Server 2012 SSMS version. IDE has many full-text setup related issues(bugs were reported to MS). And only way to achieve proper functionality was to use t-sql commands only. After SSMS became separate from SQL Server product, these IDE bugs were fixed. No problems when working with full-text and SSMS IDE anymore. My SSMS version is 17.8.1, server version 2012 - 11.0.5343.0 (X64)(Build 7601: Service Pack 1).
Maybe your problems is related with IDE bugs too? Try to upgrade SSMS version (if you have older), ant then check situation again.
Update:
Here is related topic with full-text & merge replication problem. Hope this helps:
link1
OK, so I eventually ran out of ideas and logged a call with Microsoft. Turns out that this is a bug and it effects all SQL server versions from SQL 2012 right through to SQL server 2017 from what I am being told.
Microsoft have said they are working on a patch for this but in the meantime I am having to manually script Full Text resources until something comes through.
Hope this helps anyone that comes across this issue.
I am using Schema Compare feature in Visual Studio 2017 to compare a database with database project (.sqlproj).
If I apply some changes to the project it also adds blank lines to some of the schema files.
After some investigation I found that I'm not the only one facing this issue. From the number of upvotes I can guess that MS will not fix this issue soon.
Has anyone found any workaround for this?
Not really a workaround or a solution, but I remember having this issue on Visual Studio 2017 and the issue stopped arising when I upgraded to Visual Studio 2019.
You may want to check your error list in Visual Studio. There is a good chance that there are dependent objects (e.g. Users, Logins, Tables, Keys) that the object is dependent on and is missing and not synchronized. If you synchronized those missing object to your database project first it may resolve your issue.
We currently have our database objects in TFS2012 and happily use redgate sql source control to check in & getlatest. So far this works great.
I now want to use SSDT in order to create a dacpac that defines the latest schema.
What I'm missing is how to link the SQL Server database project so that a check-in via redgate source control would ripple through to the database project (upon a getlatest) and therefore schema changes would be shown in the dacpac upon a recompile?
thanks
As it's 3+ months after I posted the question, and https://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/ I guess I should state what the outcome was...
We had a number of unresolved (at the time at least) issues automating SQL Compare, which was the reason for looking into SSDT in the first place. The more we looked at SSDT the more we became impressed with it (still has some issues, but doesn't everything?) to the extent that we have now dropped our use of redgate, therefore the need for SSDT to play nicely with redgate is no longer required.
This is not to say we're not a fan of Redgates products or that the answer is to drop redgates products - just that they didn't meet our requirements when our requirements changed (we started to automate everything).
I'll still be sending Redgate a Christmas card, honest :)
Here's a document describing how to use SQL Source Control and SQL Compare in conjunction with SSDT database projects. It's beta functionality, and we're aware of a few issues, but please report them to us (support#red-gate.com) so we can prioritize our backlog.
I'm in the process of creating a report in the latest version of SQL Server 2012 Report Builder but there are errors that I can't localize or troubleshoot because I'm not sure this functionality exists. I have the T-SQL behind this code rock solid but my question isn't about the coding, it's how can one go about troubleshooting errors in report samples through this application when all that shows up is '#ERROR' (instead of more detailed error text)?
SSRS report development in Visual Studio (or BIDS if you've only installed SQL Server) does give more options for debugging these sort of errors than Report Builder. In VS:
You can see there is a clear error message here.
As you've found, Report Builder doesn't have any sort of similar functionality - seems a pretty big oversight for a nominal development tool.
Running this report through a Report Server and checking any logged errors doesn't help, either; all that's logged is the following:
Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:
The specified operation is not valid. ;
So that's hardly going to help.
If you do have the option to use VS, do it. Report Builder has pretty much all of the same functionality, but it's situations like this when it falls over.
For what it's worth, when I've had these errors these are often due to datatype conversions (as above) - hopefully the problem expression isn't too complicated to investigate.