July 18, 2015 at 11:00 am
Comments posted to this topic are about the item Are DacPacs ready for prime-time?
Best wishes,
Phil Factor
July 20, 2015 at 6:16 am
I don't really understand the point of this shiny new tool.
More than a decade ago there were perfectly adequate methods of shipping small-scale databases around. One method was to ship a copy of a backup; another was to ship database data and log files (the database would have to be static when copies were taken, of course and that might be a difficulty in some cases, so the backup shipping version was more generally applicable); another method if the database could be made static for long enough was simply to script the database (including the data) and ship the script, yet another was snapshot replication.
At Neos we had several small databases that went to every customer site, with complete replacement 10 times a year for some dbs, less often for others (and of course other databases which contained data generated at the customer sites for which upgrades necessarily used quite different methods). Shipping the stuff around was not a problem. That was with SQL Server 2000, so I'm inclined to think this utility that using an XML encoding is a case of needlessly reinventing the wheel (a wheel with lots of sharp corners useful only to those with vast overcapacity in shipping bandwidth, since the format is XML) - in other words, it's a typical misuse of XML probably arising from people being hypnotised by the ridiculous hype that XML has received.
Tom
July 20, 2015 at 6:50 am
TomThomson
I don't really understand the point of this shiny new tool.
it's a typical misuse of XML probably arising from people being hypnotised by the ridiculous hype that XML has received
Ditto!
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
July 20, 2015 at 7:00 am
My opinion was that DACPAC's were more a resulting artefact of Microsoft's investment into its SQL Server development tool - SSDT. The DACPAC encapsulates a lot of features that come with SSDT that you wouldn't get with a traditional backup and restore method or custom built scripts for example just to name a few:
1. Centralised management of custom pre and post deployment scripts that can have the advantages of being environment specific for example for development, test and production environments.
2. Design time dependency analysis.
3. Declarative database development to make a developer's life easy so they only need to be concerned with the "what" and not have to worry about the "how".
4. Easily identify differences between the source and target.
I agree that the tools themselves are still in their infancy but they are a step in the right direction.
July 20, 2015 at 7:46 am
I don't really understand the point of this shiny new tool.
I suspect that the most important feature was to be able to update an existing database so that it conformed with the 'model' in the DacPac. This means that a 'synchronization' or 'migration' script is generated 'on the fly' and executed. I can see a use for this where all developers are working on their own 'private' versions of the database on their laptops or whatever and they need to update them to a common source what represents the 'version'. When you deploy a source DacPac to a database, it alters the database, whilst ('gulp' hopefully) preserving the data intact. If you 'register' a database, you can get reports of all changes since it was 'registered' which I suppose can be pretty useful. Bear in mind, though, that this is a dev tool, not a DBA tool.
Best wishes,
Phil Factor
July 20, 2015 at 8:03 am
We do use dacpacs, in fact they are a very important part of our development model. We develop in Visual Studio more than in SSMS, and we have several instances of complex databases with cross-database dependencies (a stored procedure in database A looks up a table in database B etc). What works best for us is to use dacpacs. We compile the database project for database B, add its dacpac file to the project for database A as a reference, and then all objects in database A's project resolve and build successfully. If you want to read more about it, I have documented it here: http://www.sqlservercentral.com/articles/SSDT/125435/
Hakim Ali
www.sqlzen.com
July 20, 2015 at 8:21 am
We are not using dacpacs. DB projects are way too kludgy for the DB sizes we typically deploy and, as I understand it, are required if you intend to use dacpacs. We have many, many hotfixes, enhancements, etc. being worked any given week on multiple products which would mean a DB project for each. They don't produce any SQL scripts for validation or comparison. And the xml...never been my favorite format to work with.
We rolled our own and so far it's been working great and allows an entire database or just a solution to be deployed very quickly, with full visibility. We use a mix of .NET, SQL, 3rd party compare tools, and Powershell. The only xml in the mix is for configuration files. All artifacts generated are either SQL scripts, log/error files, or a deployment package, similar unto the dacpac, but encrypted.
July 21, 2015 at 2:20 am
Dacpacs are pretty cool, personally I think that the internal format is irrelevant, it is a bit like saying that the CIL for .Net isn't good.
The benefit that we get is with SSDT in that we can write and more importantly refactor code within visual studio to create a dacpac. The dacpac is just the deployable artifact which has an API around it which is useful because it means we can query it and write tooling around it to build out CI/CD processes.
The real killer feature of SSDT is that I can rename a table and it will generate an sp_rename, rather than something like the Redgate SQL Compare tool which will drop the old data and create a new one (eeek).
I don't think dacpac's have been helped by the support in SSMS, extract or import rarely works for me but maybe I am doing something wrong.
SSDT enables developers to write and refactor code in a way that no other RDBMS that I know of has. The best you get with any other system is manual upgrade scripts with dbup.
July 21, 2015 at 2:37 am
With Agile , Continuous Build and DevOps now , DACPAC has a very important role to play. Inf act it is considered one of the best ways to move databases to the cloud. Its usefulness is more obvious when we look at failed build and releases where dependencies and rollbacks are not handled properly.
Moving code to dev , pre prod , testing etc has never been easier. It think its not understood well enough by most Database folk but once you use it you'll never go back.
Version , change detection and deployments are all streamlined and become a job of minutes rather than days as before.
July 21, 2015 at 2:47 am
I was also going to say that in the editorial you mention that it missed some differences - you should definitely raise connect items or post them in the SSDT forum so the product team can fix them.
I've never seen this so it would be interesting to know in what cases it doesn't work.
July 21, 2015 at 3:43 am
Ed,
I was also going to say that in the editorial you mention that it missed some differences - you should definitely raise connect items or post them in the SSDT forum so the product team can fix them.
I think I tracked it down, but it was quite bizarre. It turns out that SMO thought that a table that had been deleted was still there (caching somewhere?) and when it came to get its attributes, it found it wasn't and so gave an exception. This exception was swallowed by DacFx rather than abort the comparison, so that it said that there were no differences. This behavior occurred whether I used DacFx directly of via the command-line executable.
Best wishes,
Phil Factor
July 21, 2015 at 3:47 am
cool, stick it on connect as it sounds quite serious!
March 25, 2016 at 3:35 am
This sounds like a tool that is not yet mature yet has shown some promise. The next time I am on a project utilising SQL Server I shall certainly investigate.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply