When I'm publishing a new database that contains multiple filegroups and files, the file groups dont get published on the creation of a DB. When the DB is being upgraded it works, which means I need to call sqlpackager.exe twice to publish a database.
Objective:
Create a database with filegroups(shared component) that break up configuration data from sales data.
Implementation:
Main database project references a common database project that contains a collection of file groups only. The DB reference has been correctly set up. The publish file being used with the deployment of the dacpac correctly sets the property: IgnoreFileGroupPlacement (FALSE)
The main database project has a list of files to add to the file groups.
I'm creating a filegroup called "defaultworkingspace" to move everything off primary except system objects, i've marked this filegroup as default.
When I deploy for the first time, I get the below error:
Initializing deployment (Start)
*** A project which specifies SQL Server 2008 as the target platform may experience compatibility issues with SQL Server 2005.
*** The following SqlCmd variables are not defined in the target scripts: SourceCode SourceId.
Initializing deployment (Complete)
Analyzing deployment plan (Start)
Analyzing deployment plan (Complete)
Updating database (Start)
Creating Register_DB...
An error occurred while the batch was being executed.
Updating database (Failed)
*** Could not deploy package.
Warning SQL0: A project which specifies SQL Server 2008 as the target platform may experience compatibility issues with SQL Server 2005.
Warning SQL72013: The following SqlCmd variables are not defined in the target scripts: SourceCode SourceId.
Error SQL72014: .Net SqlClient Data Provider: Msg 5014, Level 16, State 2, Line 1 The filegroup 'DefaultWorkingSpace' does not exist in database 'Register_DB'.
Error SQL72045: Script execution error. The executed script:
ALTER DATABASE [$(DatabaseName)]
MODIFY FILEGROUP [DefaultWorkingSpace] DEFAULT;
The setting of the default has been made as part of a post deployment script so it should be running with all post deploy scripts. When I deploy it again, now as an upgrade as the db has been created
Initializing deployment (Start)
*** A project which specifies SQL Server 2008 as the target platform may experience compatibility issues with SQL Server 2005.
*** The following SqlCmd variables are not defined in the target scripts: SourceCode SourceId.
*** The source's object [Register_DB] is different than the target's version of the object but the target object will not be updated.
*** The object [Register_DB] already exists in database with a different definition and will not be altered.
Initializing deployment (Complete)
Analyzing deployment plan (Start)
Analyzing deployment plan (Complete)
Updating database (Start)
Creating [Configuration]...
Creating [DefaultWorkingSpace]...
Creating [Giftcards]...
Creating [Logging]...
Creating [MasterData]...
Creating [Mobile]...
Creating [Sales]...
Creating [Config]...
Creating [Working]...
Creating [Giftcards]...
Creating [Logging]...
Creating [Master]...
Creating [Sales]...
It seems odd that the upgrade process supports the filegroups but the initial creation of the DB does not... Has anyone come accross this issue before?
Known issue with dacpac apparently.
I went with the approach of deploying a db project to master prior and creating the db's if they didn't exist in post scripts for that db. Not the cleanest but it'll do for now.
Related
Goal
Clone a SQL database to a different remote SQL Server using a PowerShell script
What Works
Using SSMS to import the BACPAC file into different servers (remotely & local) works without (reported) warnings or errors.
What Doesn't
Importing the BACPAC into a remote SQL Server results in the following error using sqlpackage.exe & PowerShell dbatools:
Warning SQL72038: The object [XXX] already exists in database with a different definition and will not be altered.
Error SQL72014: .Net SqlClient Data Provider: Msg 15023, Level 16, State 1, Line 1 User, group, or role 'XXX' already exists in the current database.
Error SQL72045: Script execution error. The executed script:
CREATE USER [XXX] FOR LOGIN [XXX];
I also tried using PS dbatools DACPAC approach: https://dbatools.io/clone/
The error message with different settings changed to:
Initializing deployment (Start)
The object [XXX] already exists in database with a different definition and will not be altered.
Initializing deployment (Complete)
Analyzing deployment plan (Start)
Analyzing deployment plan (Complete)
Reporting and scripting deployment plan (Start)
Reporting and scripting deployment plan (Complete)
Updating database (Start)
Creating NEW_DATABASE...
The database settings cannot be modified. You must be a SysAdmin to apply these settings.
Creating [XXX]...
.Net SqlClient Data Provider: Msg 15023, Level 16, State 1, Line 1 User, group, or role 'XXX' already
exists in the current database.
Script execution error. The executed script:
CREATE USER [XXX] WITHOUT LOGIN;
An error occurred while the batch was being executed.
Updating database (Failed)
The next step was then to disable users and add back the required users & roles via a script. Using the following link as a reference, resulted in a database that I was unable to drop with our existing administrator login & password.
DacPac exclude users and logins on export or import
To fix this, we had to change our administrator password in RDS
AWS RDS SQL Server unable to drop database
Notes
I can't remove user XXX because it's mapped to different databases
SQL Server Management Studio v17.9.1
PowerShell dbatools v1.0.30
Questions
Is there a way to find out what SSMS is executing so that I can replicate it via a script?
What are the options to work around this issue?
This is very late to answer, although I will share my inputs here so someone in future can find it helpful to solve the problem.
This is what I did with some exceptions. Exclude the object types = Users;Permissions;RoleMembership;Logins; in the sql package command line property to successfully deploy the database.
The exception is, you will not be able to deploy your users, permissions on the already existing set. On a fresh install, you could remove this exclude property to deploy the entire set without errors.
Here is the commandline parameter to use in your sqlPackage.exe command
/P:ExcludeObjectTypes=Users;Permissions;RoleMembership;Logins;
Ref: MS DOCS -> https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage-publish?view=sql-server-ver15
I have a problem with unresolved referenced in synonyms with a VS2013 Database project I have created for Team Foundation Server, which cause the project to not build. The synonyms reference another Database on the same server. I have seen online there are 3 main ways people handle this. I am going for this approach 1.
Create a DPAC file and add as a Database reference in Visual Studio Database Project.
Bring in the other database project in the current team Foundation Server project ?
Set the build action to None for the failing scripts that have the unreferenced synomns.
So when I go to extract the DPAC file from the Database it fails with an error.
Validation of the schema model for data package failed.
Error SQL71564: Error validating element [UAT_*********]: The element [UAT_*****] has been orphaned from its login and cannot be deployed.
( There is about 9 similar messages with other logons as well)
Is there anyway to bypass this and generate a valid DPAC file from sql server ?
If you need a .DACPAC file as a reference to your database projects, there is no need for referencing object to have any real code - As long as the signature met the requirements that the reference from Database Project was looking for, it will be just fine (syntactically valid).
You do not have to create a .DACPAC directly from SQL Sever, you can create a new empty Database Project, create/import all objects needed as references and then "Snapshot Project". This will generate valid .DACPAC and keep the size to minimum, which then you can put under source control.
If you wanted to create a .DACPAC from SQL Server, then I am afraid you would have to delete those objects, because it is unable to find logins in master database that are associated with them.
Great article to read about your approach 1 :
A complex database project
Hope this helps.
RESOLVED SEE EDITS:
Like a total noob I deleted our ReportServerTempDB by accident (I have a backup of ReportServer but not ReportServerTemp, live and learn). (Using SQL Server 2008 R2)
To recreate the database I followed several online guides that gave the several steps:
created a new database with the name ReportServerTempDB, and with the same collation as ReportServer (collation was key)
made a new Database Role called RSExecRole with same users as my ReportServer (also key to make sure this role has the correct permissions to the tables)
ran the CatalogTempDB script which ran without a hitch (the version of CatalogTempDB was not sufficient to recreate all of the objects necessary)
Used Reporting Services Config Manager to Change Database and picked ReportServer
Just for good measure turned off and on the SQL Server Reporting Services a few times
But I am still getting an error when I try to load my Reporting Services Home page:
An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database. (rsReportServerDatabaseError) For more information about this error navigate to the report server on the local server machine, or enable remote errors
What am I forgetting? As an alternative can I simply "create a new report server database" and import a back-up of my original ReportServer? TIA
EDIT: I reviewed the RSExecRole and made sure that it had permission to edit tables and execute stored procedures (online sources did not spell this out very clearly) and after restarting the Reporting Services my error has changed to "An error occurred within the report server database. This may be due to a... Invalid object name 'ReportServerTempDB.dbo.TempCatalog'. Could not use view or function 'ExtendedCatalog' because of binding errors. "
Further reading is suggesting that the name of the temp Report Server is hardcoded into many stored procedures in ReportServer, but my new temp report server has the same name: ReportServerTempDB. Where is the disconnect?
EDIT2: So the script I used, CatalogTempDB, did not create all of the tables necessary to rebuild my temporary Report Server db. I created a new Report Server and ReportServerTempDB (which an altered name) and compared the object in my ReportServerTempDB built using CatalogTempDB to the one the SQL wizard created. Then used the import wizard to add in the missing tables and re-started the Report Service with my original. Voila.
Happy to provide more details about any of these steps.
To recreate the database I followed several online guides that gave the several steps:
created a new database with the name ReportServerTempDB, and with the same collation as ReportServer (collation was key and you need to assign it when yout are creating the db)
made a new Database Role called RSExecRole with same users as my ReportServer (also key to make sure this role has the correct permissions to the tables and stored procedures)
ran the CatalogTempDB script which ran without a hitch (the version of CatalogTempDB was not sufficient to recreate all of the objects necessary, several tables were missing)
To replace the missing tables I created a second ReportServer instance (using Reporting Services Configuration Manager)and compared the temporary db to my re-built temporary db and filled in the holes
Moral of the story: Keep a back up of BOTH ReportServer and ReportServerTempDB
Full error below:
Error 1 SQL01268: .Net SqlClient Data Provider: Msg 1834, Level 16, State 1, Line 1 The file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\testdatabase.mdf' cannot be overwritten. It is being used by database 'testdatabase'. SchemaCompare5 25 0
I read about this on some forums and quite a few people were getting this and supposedly for some it had to do with parameterising the file path name to the db etc. or ticking "ignore file names and path for files and log files" prior to doing the comparison - this I have tried to no avail.
Someone else who has the same/similar issue: http://social.msdn.microsoft.com/Forums/en/vstsdb/thread/5a8b8c52-adb4-4a5a-95ed-09ad22bacf60
Basically for me I seem to get this error irrespective of which databases I am using for target and source. Say even if I create a new database with one table and another database with no tables and different name and try to update the schema of the database with no tables using the db with the single table it still gives me the error. Almost like SQL server express has gone nuts. I remember using the schema comparison tool before with no trouble. All db connections were created, tried many ways to do this to no avail ie: pointing to copy of *.mdf db in another folder or deleting things from the DATA folder in mysql directory in program files etc.
Also believe I read someone had solved a similar issue be deleting some files the scheme
comparison tool creates, think they were *.sql type not sure which ones though.
The problem arises because the database files already exist.
Try the below within the Visual Studio database project.
Create the schema comparison.
Go to menu: Data > Schema Compare > Export to > Editor
Once the script has been created delete the alter database commands that add the physical files. Then create a connection, switch to SQLCMD mode (making sure you have focus on the script) and execute the script.
To switch to SQLCMD mode access: Data > Transact-SQL Editor > SQLCMD Mode
If the target DB already exists, just delete through Management Studio first before you deploy for the first time.
I had already created the database manually through SQL Server Management Studio when I was establishing the original connection when creating the Database Project via the SQL Server 2008 Wizard in VS. It wouldn't allow me to continue until it could detect that the database existed. Then once I got to the Deploy step for the first time, it threw the same error as above. I just went into Management Studio and deleted the DB, then tried to deploy and it worked fine. Interestingly, it's deploying every time now without me having to go in and delete it every time.
RESTORE DATABASE B FROM DISK = 'A.bak'
WITH MOVE 'DataFileLogicalName' TO 'C:\SQL Directory\DATA\B.mdf',
MOVE 'LogFileLogicalName' TO 'C:\SQL Directory\DATA\B.ldf',
REPLACE ---> Needed if database B already exists
I'm introducing Tarantino Database Management into a project, which has a brand new database schema. The only change (located in 0001_InitialSchema.sql) is the creation of the tables used in ASP.NET Membership. I generated the tables using aspnet_regsql.exe and then scripted them as CREATE TO scripts, then combined them into my single Tarantino sql file.
Upon running my NAnt build script, the drop database command chokes when trying to drop all connections from the database it's trying to drop.
Dropping connections for database DBName
[call] An exception occurred while executing a Transact-SQL statement or batch.
[call] Only user processes can be killed.
This causes the following create database step to fail since the database still exists, and no new updates will be applied:
ManageSqlDatabase:
Create DBName on localhost using scripts from path\to\source\src\Database
BUILD FAILED - 1 non-fatal error(s), 0 warning(s)
INTERNAL ERROR
Microsoft.SqlServer.Management.Common.ExecutionFailureException: An exception occurred while executing a Transact-SQL statement or batch. ---> System.Data.SqlClient.SqlException: Database 'DBName' already exists. Choose a different database name.
Some system process always remains attached to the database well after the script has run. I've tried running this on different machines and the same problem exists. I've also tried running a different Tarantino project, and it runs flawlessly every time. I even created a dummy update file (which added tables Foo, Bar, etc) which also ran without issues. The problem seems to stem from the CREATE TABLE scripts for the ASP.NET Membership tables.
You can find a copy of the SQL update script run at PasteBin (separated from post due to its length).
That would be a bug in Tarantino aparently. If you look into DropConnections.sql you'll see that the author has fallen for the old myth that any session above 50 is an user session. The correct way to identify user sessions (and thus KILL-able sessions) is to check the is_user_process column in sys.dm_exec_sessions.