I read a few articles over the weekend and learnt a few things that I think might be worth bringing to folks’ attention.
ODBC Administrator gets a lick of paint in Windows 8/Windows server 2012
The ODBC Administrator in Windows 8 has had some minor improvements. There’s now no longer a 32bit & a 64bit version of it, there’s only one and it has a new column to tell you whether the 32bit, 64bit drivers or both are installed.
There are also a few PowerShell cmdlets to help with administration of ODBC Data Sources which if you’re a fan of automating deployments (as I am) is great news. Read more at ODBC DSN Management in the Next Release of Windows (code-named Windows “8” and Windows Server “8”).
Bacpacs days may be numbered
Bacpacs are files that act as an easy portable backup of schema+data of a SQL Server database and are typically used to move data between an on-premise SQL Server instance & Windows Azure SQL Database (aka SQL Azure). Recently however Dacpacs gained the ability to deploy data also so I asked the question on the SSDT forum Given that a dacpac can now deploy data, why would I ever need bacpacs? Gert Drapers, who until recently ran the team that builds SSDT and the DAC Framework, replied with:
BACPACs are a left over of the past more then anything.The main reason will be that most of the existing tooling, SSMS 2012, the Azure management portal and teh Azure Import Export service, only support BACPACs.
Right now the data support between the two is identical, DACPAC are or were supposed to add incremental data deployment, as right now it expects an empty table to load the data in to. Overtime I expect BACPAC to fade away and its usage to be replaced by DACPAC with data.
In other words the only reason right now to use dacpacs is that that is what the tooling supports however you should expect that to change in the future. Note that Gert is no longer on the team that builds those bits so don’t quote this as being a formal roadmap.