I am using database project to deploy database in continuous deployment manner as well as QA Server database deployment. But still I have lot of confusion to use the .dacpac versions?
Also, If I have .dacpac 1.0,2.0,3.0,4.0. Now I have using version 4.0 in my database, But some scenario that will I need dacpac version 3.0 on same Sql Server. Is it possible? If yes, then How can I achieve same?
Related
I'm currently working on a enterprise that uses TFS 2017, and we pretend to upgrade to Azure DevOps. So far I'm just studying about how to implement this TOOL. I'm new on devops things and I have these following doubts... Why do we need SQL Server to install DevOps Azure? What kind of information are stored in there?
In the server configuration wizard, I have the option to select an existing database to use for the Azure DevOps Server that's being deployed... Can I select the currently database that's used by TFS 2017?
Azure DevOps Server and Team Foundation Server store just about everything in massive SQL Server databases.
The main server configuration is stored in the tfs_configuration database and each project collection is stored in a separate database The default is tfs_defaultcollection.
The collection database holds all version controlled files (TFVC and Git), all work items (Product Backlog, Sprints etc), Test Cases and all test run attachments, your Pipelines, Builds and Releases as well as all of the artifacts produced by these pipelines.
These databases can grow considerably.
Whether you can keep your current database server depends on what version you're currently running. SQL Server 2016 SP1+ happens to be supported by both Azure DevOps Server 2020 as well as Team Foundation Server 2017. You could keep using that for the upgraded installation.
But my recommendation would be to install SQL Server 2019, you'll get all of the performance and security benefits of the new server, support for the latest Windows Server platform, as well as a support window that matches your new Azure DevOps Server installation.
You can find the SQL Server compatibility matrix for TFS/ADS here:
Azure SQL Database and SQL Server
TFS 2017 was one of the last versions to require a database for the Warehouse, which is a form of replicated data. Reports can be written to pull data from the warehouse, without impacting the user experience. The database is somewhat deprecated now, especially for reporting. Microsoft promotes the use of the API to pull data from the live database. TFS does however still need its "live" database to store all of the data presented to users. These will be work items, discussion comments, project templates, user mappings to AD, amongst other things.
You will need to upgrade your 2017 Schema to conform to the new standard as defined by Azure, which will be taken care of as part of the upgrade.
What kind of information are stored in there?
Issues, templates, build results, lots of things.
Can I select the database that's used by TFS 2017?
Yes, that will be upgraded during the installation.
I'm trying to upgrade my TFS2017 Update 3 environment, to a new Azure DevOps Server (on-premise) environment.
I've created a new server for Azure DevOps Server, as I'd like a newer version of Windows Server, and in general just want a completely fresh environment. I took backups of my databases, shut down the old TFS2017, without deleting anything.
I migrated the databases to a new SQL Server instance (where I have all my other databases), as I see no need to use an SQL Server license just for source control.
Now comes the fun part. I tried to configure Azure DevOps Server to use the existing database (after the migration to the new SQL server instance was done). I had some issues with the TfsJobAgent service, but got those resolved.
I then tried to reconfigure Azure DevOps Server (as it failed the first time), but during configuration, it now tells me that data is corrupt, and that the existing database cannot be used. Good thing that I took backups :)
It should be said, that the new SQL server instance is a 2019 version, so that shouldn't be a problem.
I'm not quite sure what is happening here, and why it's giving me this error. Am I migrating in a wrong way? There's not much documentation out there describing this flow.
Please go through the documentation below before upgrade:
https://learn.microsoft.com/en-us/azure/devops/server/upgrade/get-started?view=azure-devops
And follow the steps in article Upgrade scenario walkthrough for Team Foundation Server to upgrade your TFS. Summarize the steps here:
Prepare your environment. The first step is to check the system requirements for TFS 2018. Upgrade SQL Server is
necessary for your scenario. Including SQL Server, you also need to check other system
requirements and prepare the environment.
Expect the best, prepare for the worst. You must have a complete and consistent set of database backups in case something
goes wrong.
Do the upgrade. Once the preparation is done, you'll need to install the new version of TFS to get new binaries, and then run
through the upgrade wizard to upgrade your databases.
Configure new features. Depending on what version you upgraded from, you may need to configure each team project to gain access
to some of the new features made available.
I'm currently working on an application that runs a small SQLite DB, but I want to use .RDLC for reporting.
I generate the reports over my view models, the idea was for them to be decoupled from the DB, but now I run into this snag that I have to install SQL Server in order to use the reporting framework.
I wouldn't want to require my clients to install SQL Server on their machines just to be able to generate reports. They won't be happy about that. And I don't want to redesign my reporting component either(I have something from a previous project which used SQL Server and that works very well. I want to reuse it)
Is there a way to deploy the Reporting framework on the target machine without SQL Server?
Ideally I would like to just just copy the needed libraries in my application's installation folder, under OTS, but I don't really know which libraries to copy and what I can leave out or even if it's going to work this way.
Any insight would be helpful.
No. SSRS will only work on a machine with SQL Server installed on it.
Same with SSAS and SSIS.
So what we ended up doing is installing two nuget packages.
Microsoft.ReportViewer.Windows and Microsoft.SqlServer.Types
This will allow us to use the reporting framework without deploying SQL server on our target machines.
I am developing an application that will use SQL Azure for the production database. I will be developing locally against SQL Express on my machine. If I make changes to the schema, how do I migrate those changes to SQL Azure but still retain all of my production data? For the initial migration I used SQL Azure Migration Wizard, but that was before I had any data. Should I make a backup of the data, recreate the database with the new schema, and then restore the data?
I think that its a general schema versioning question. One possible solution is having migration scripts that you write and test during development and run on production during deployment phase. Entitiy Framework offers migrations as one of it features. My current prefered tool is FluentMigrator. I works for Azure Sql as well.
In order to migrate changes to SQL Server but still retain all of your production data, it is highly recommended that you version your database schema. This also applies to SQL Azure and all other RDBMSs.
This is very important when there are several developers working on a project but I believe it is also advantageous when you are working on a project by yourself.
RoundhousE is one of several simple tools you can use to achieve database versioning. It served us well for this purpose for the past 4 years: https://code.google.com/p/roundhouse/
I am on a shared host and whilst in development (umbraco) I think it would be easier to use VistaDB then package up to install to SQL Server. However, I have already started using SQL Server. Is there a way to migrate my SQL Server (2008) database to VistaDB. I assume the schema is identical but I need a way/tool to move the data to VistaDB.
You could migrate to VistaDB in the same way that you want to migrate data from development to production. Create a package from your current SQL Server-based development site, then create a new empty install of Umbraco with a VistaDB database and import the package there.
This would also be a useful dry run to check that migration to production is going to work as smoothly as you expect.
You can also use the Data Migration Tool in VistaDB to migrate any SQL Server database to VistaDB 4. If you need an older migration (I think the current Umbraco is still using VDB3 files) contact support through the VistaDB.Net site and someone will help you.