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.
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.
Where I work, we are using SSIS to generate several reports. They've been running fine for over a year, possibly much longer, but the people to setup and configured the system are no longer here and I am a web developer, I have no experience with SSIS yet, just standard SQL.
Since the middle of July some of the data is no longer being added to the report. I investigated the server it runs on and found that the following error in the Event Viewer started occurring once a day since the day the data no longer appears in the reports.
Package "Populate fact_PageRequest" failed.
However I can't find any further information about what could be causing the problem.
I opened the .dtsx files in the repository for the reports and found "fact_PageRequest" referenced in one of the flowchart sections of the file, but these reports haven't changed since they were made so I'm guessing it's something more configuration or environment related.
Any suggestions or advice on where to look for more information about the error or possible causes would be really appreciated.
The server it's running on is Windows Server 2012 R2 and SQL Server 2014 if that helps.
There are a few ways to troubleshoot packages. The easiest way assumes that you are using project deployment mode and did not explicitly switch off default logging. Here are the steps:
Connect to your database engine with SSMS
Expand "Integration Services Catalogs" node
Expand SSISDB and locate your package
Right click the package -> Reports -> Standard Reports -> All executions
If the package is not there, it is either stored in the msdb database or in the filesystem and other logging way will have to be applied.
I am trying to backup my entire SQL Server database, so I can restore it in case I mess something up (about to revamp my entire Umbraco site). However, according to Microsoft's guide (and others' as well), there should be a task called Back Up. However, there is not.
That is for SSMS 17 (version 14). SSMS 2016 (version 13) shows the exact same thing.
To backup a SQL Azure database you need to select the "Export Data-tier Application..." option.
This will create a .bacpac file which you can then restore to either another SQL Azure database or an on-premises SQL Server.
See the Microsoft Documentation here for more details.
In Azure SQL DB, backups occur automatically. If you want to export a database, you can export to a BACPAC (make sure active transactions are not occurring during the export). See https://learn.microsoft.com/en-us/azure/sql-database/sql-database-automated-backups and https://learn.microsoft.com/en-us/azure/sql-database/sql-database-export.
For me the problem was the database name, of all things. I know it sounds weird, but while researching this issue I discovered a bug in SSMS that causes the context menu to change (including not having backup/restore options) based simply on the database name.
I'm using 18.4, but the bug likely exists in earlier versions as well.
I've reported the bug here, but I'll summarize the steps to reproduce the issue here for convenience:
In SSMS, Right-click the Databases node, choose New Database...
Name it 1.2.3.4, click OK
Right-click on the newly-created database. There is no option to Back up (or restore)
Click on the name (so that you can rename it)
Rename the 1.2.3.4 database 1234 (remove the periods)
Perform step 3 again - this time you'll see the expected Back up... and Restore options.
It appears that the context menu for SSMS is incorrectly assuming the database type because of some pattern in the name involving periods. As for the specific pattern, I don't know. I do know that periods in general aren't a problem, but names like 1.2.3.4 are problematic. Test_1.2.3.4 is fine. I'll leave it someone actually debugging the problem to figure it out.
Hopefully this will help someone else that comes along looking for answers.
My boss tasked me with doing research on migrating sql server 2005 to 2014.
my first question is, is it really as easy as restoring into an old backup?
No thing needs to be changed in terms of processes that load to the databases or components that look at the databases?
I'm completely new to this, obviously. I use SQL server management studio almost every day, yet I am still not familiar with anything else besides running a few simple queries.
I've looked at this site here that finds all permissions/access for all users in a database. I've also run sp_who2 and:
SELECT *
FROM
Master..sysprocesses
order by spid
just to get an idea of all the processes going on. How would I see the websites that are pulling from the databases? I know we have a DB loader, how can I see that process?
I can't quite get a grasp of the scope of this project.
It can be as simple as backup and restore or an in-place upgrade, but there are subtle changes with each new edition that mean there's no way to be sure that it will be without thorough testing. There's hundreds of things that may catch you up caused by 10 years and 4 different revisions. Some might be as simple needing to fix SQL Users and SQL Login mapping, to changes to the SQL client causing incompatibility, to functions or methods that simply no longer work or work differently. It's impossible to tell without knowing your data and your database. The first step should be getting the documentation from your application vendor, assuming it's an application with support.
I strongly recommend that you start reading the MSDN doc on installing and upgrading SQL Server 2014, and you may need to read the 2008, 2008 R2, and 2012 doc as well to look for changes that might impact you. I'd strongly recommend setting up a testing environment to make sure that your application will even work.
Bottom line is that you should not assume that it will work without thorough investigation, planning, and testing.
Our SQL Server has over 8000 databases.
To expand the database-node in my SSMS (2012 and 2014, both) takes around 2 minutes, sometimes longer (when there is a lot of traffic).
Is there any way to reduce this time?
I read somewhere, don't know where, that the problem is, that for every database the SSMS asks if you have rights to see them, open them, expand them (or something like this).
You would need to revoke the permission 'VIEW ANY DATABASE' from the role PUBLIC (SQL SERVER 2005 onwards) and give permission to the users only for the databases they need. This should make Object Explorer faster.
I had a similar issue with Sql Server 2014. It took me about 1 minute to expand the databases tree with only 10-15 databases listed.
The solution to me was to run the Sql Server 2014 setup and repair the installation. Even though nothing seems to be incorrectly installed this still fixed the issue for expanding the databases tree.
Rene,
Have you tried using the latest preview version of SSMS (available here)? I believe the issue might have also been addressed in the SSMS 2014 Service Pack 1 release (you can find that here)