Is database TRUSTWORTHY ON necessary for tSQLt to run? In our DB environment, we can't set TRUSTWORTHY ON for databases.
Does tSqlt run with the database status of TRUSTWORTHY OFF?
Related
We are using Sybase Replication for our environment, there is a capability on the Sybase that we can issue a command set replication off, if these commands is executed, all the following DML commands to be executed on the standby database for the current session will not be replicated.
Link: https://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc32410_1501/html/refman/X30234.htm
Now, we are checking the SQL Server Replication if they have the same capability. Thank you!
I have a Database Project. I am trying to deploy that project against a database. The Database deployment is inadvertently dropping SQL Broker objects in database not in source (database project) if the user is not a sysadmin
Using Visual Studio and using Dacpac deployment gave same results. In my publish profile, Drop is unchecked, so it should not try to drop objects in target that are not in source. That is working fine if the user account is a sysadmin. But if it is not, it is dropping all sql broker objects in the database that are not in source
I finally found the reason for the database deployment behaving differently for sysadmin vs non-sysadmin. I ran a sql trace while I did "Generate Script" from Visual Studio database publish.
During the non-sa publish, the trace captured an exception in tempdb database that said "this "Cannot alter the schema 'dbo', because it does not exist or you do not have permission.".
I had a script with "CREATE XML SCHEMA COLLECTION" as part of my database project which was failing due to insufficient privilege.
Because of this exception, the deployment process was deciding to generate all those "Drop" statements in the publish script. As soon as I granted the user account dbo access to tempdb and re-generated publish scripts, the drop statements went away from the publish scripts.
I am trying to publish a SQL Server database using a .dacpac and publish profile to an Azure SQL database. We have been using on premises SQL Server with no problems for quite some time, and now we are evaluating Azure and AWS to see which is best suited for our needs.
We have a SQL Server database project and want to deploy it to Azure SQL database, however it fails to execute the script generated by SSDT. This is because the generated script contains a call to the stored procedure sp_MSforeachtable which does not exist in Azure SQL.
I also have changed the target platform from SQL Server 2016 to Azure SQL V12. I am trying this from Visual Studio 2017's publish profile and from VSTS Release management using Azure SQL database deployment task. An of course by providing the necessary .dacpac and publish.xml files in the task.
I know I can manually add the stored procedure, however it doesn't seem that is what is intended by these publishing/deployment methods. Does anyone have any ideas?
Thanks
sp_MSforeachtable is an undocumented stored procedure in the Master database. This apparently hasn't been ported over to Azure SQL. I believe you'll need to add it manually to the Master database. Once that is done, your DACPAC should work just fine on your own Azure SQL database. I don't see a problem with manually adding sp_MSforeachtable. DACPACs are meant to keep your database in sync, not the Master database.
This feature is not implemented in SQL Database in Azure.
You can find a copy of it at this location: https://gist.github.com/metaskills/893599
Correct, sp_MSforeachtable stored procedure is still missing in Azure SQL, but you can easily create it manually. It is very helpful when you have to rebuild indexes for all tables at once:
exec sp_MSforeachtable #command1="DBCC DBREINDEX ('?', '', 80)"
Having successfully taken a database instance offline using the Management Studio I then attempted it bring that same database back online both using the Management Studio and by executing the following script.
ALTER DATABASE [dbname] SET ONLINE
This results in the following error
User does not have permission to alter database 'dbname', the database does not exist, or the database is not in a state that allows access checks.
Turns out that on RDS you can use the standard SQL script above to take an instance offline, but Amazon require you to execute a stored procedure to bring it back online;
EXEC rdsadmin.dbo.rds_set_database_online dbname
See here for more http://docs.amazonwebservices.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.html
I am using SQL Server 2008, developer edition. I connect to my database from my asp.net mvc application using Linq2SQL. I noticed that my database went into recovery mode about 4 times in a span of a month. I am running a few complext Linq2SQL queries. When database is in recovery mode, my asp.net mvc application is going off line as it could not connect to the database. I do not know how to prevent the database from getting into recovery mode. I have seen some of the questions on SO, but could not find a way how to solve it. I am hoping some one could help me out.
Some possibilities/things to check include:
Is this database part of a Log
Shipping configuration? If so, whilst
the Secondary server is being
restored you will be unable to
establish connections to the
database.
You are certain you are using the Developer
Edition of SQL Server and not the
Express Edition?
Is the Autoclose option set to TRUE?
If so the database will shutdown when
there are no active user connections.
To check if you have any databases set to Autoclose use the following T-SQL:
SELECT * FROM sys.databases WHERE DATABASEPROPERTYEX(name, 'IsAutoClose') = 1