I have just upgraded to the Azure 1.7 sdk and have now lost the contents of my devstorage.
I can still see it in the local instance of sqlexpress (as DevelopmentStorage20110606), but when I use UseDevelopmentStorage=true, it longer connects to this.
Where has the new development storage db gone? I need to import my data from the previous version, as we use local storage for testing on the build server and have test data setup on it, or is there an upgrade script to be able to port this data accross.
Thanks
SDK 1.7 now uses IIS Express (compute) and SQL Server 2012 Express LocalDB (storage). You should be able to point your emulator to your existing database by running dsinit.
Michael Collier talks about the 1.6 vs. 1.7 differences in his post, here.
More information about LocalDB is here.
DSInit documentation is here.
Related
I have an application in Node JS which uses Oracle cloud anonymous database which is currently working perfectly with my application at local.
I wanted to deploy this app on Azure App Service and so I followed this Microsoft Doc Link using this I was able to deploy my project and it is running on the server but unfortunately it is not able to connect to my oracle could database
while deploying I got some logs which says this
** Node-oracledb 4.2.0 installed for Node.js 14.17.4 (linux, x64)
oracledb **
oracledb ** To use node-oracledb:
oracledb ** - Oracle Client libraries (64-bit) must be configured with ldconfig or LD_LIBRARY_PATH
oracledb ** - To get libraries, install an Instant Client Basic or Basic Light package from
oracledb ** https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html
oracledb **
oracledb ** Installation instructions: https://oracle.github.io/node-oracledb/INSTALL.html
oracledb
so from this, I somehow understood that I need to configure the Oracle client on a Linux server so after spending hours I got a solution where I need to set up the path here is the Oracle Doc but even this settings did not worked for me still not able to connect it.
also, one more thing I noticed was as soon as I redeploy or restart my App Service the settings get vanished
for oracle, I have database name, password, connection string, and oracle has also provided me with waller.zip which has tnsnames and cwaller.sso
have spent 3 days understanding the problem, if someone can help with it would be great, please comment if you need any more details to understand my problem
This is not a full answer (i.e. it's too big for a comment).
Start by upgrading to a recent version of node-oracledb, e.g. 5.2.
It sounds like you know what to do with the wallet files, but here is the node-oracledb doc on Connecting to Oracle Cloud Autonomous Databases. If you don't have the wallet files in a default location you can (with node-oracledb 5) use initOracleClient({configDir:'/your/path'}) to indicate their location.
The final piece is to set LD_LIBRARY_PATH to the location of your Instant Client libraries. Search for Azure doc on how to do this - I don't have experience with this environment.
Just recently converted our 2.8 Azure Project to 2.9 and suddenly this started happening.
We're using a classic cloud service to host a web application. Don't understand why it suddenly starts to go bananas on the CPU load.
The process that seem to be using the CPU is called CollectGuestLogs.exe. Can I disable it somehow?
We did open a ticket and found a solution to this issue:
"Actually the CollectGuestlogs.exe is used by azure to generate the diagnostic log file and to zipped it.
This file exists in your PaaS VM instance in the below path
D:\Packages\GuestAgent
First we have provided the temporary fix to confirm the issue like renaming the CollectGuestlogs.exe and check whether the process is running after restart the VM instance once.
As you confirmed that our temporary work around was successfully resolved your issue. We found that this issue is related to a known issue with the Azure SDK 2.9 that it is going to fixed in the hotfix release of Azure SDK version 2.9.5.1." -Microsoft support
I have multiple Azure SQL databases. One database holds all the staging table and the other database holds all the fact/dim tables. Now in my development environment I have stored procedure which reads data from staging tables (from staging database) and loads the data into its respective fact/dim tables (in a different database).
The above scenario is all working fine. I have multiple SQL projects for each database.
Now how do I deploy the elastic database queries while deploying the dacpac?
Below is the error when I add the elastic queries as a part of my post deployment scripts in Visual studio and try to build it.
PS: The SQL project properties is set to target the V12 version of the Azure SQL Database
Which version of the SQL Server Data Tools (SSDT) are you using? If you are not using the latest (14.0.60413.0), give it a try to upgrade SSDT: https://msdn.microsoft.com/en-US/mt429383. With that version, I am now successfully able to compile and publish database projects and dacpacs.
To successfully build, you will need to install the latest SSDT Preview which includes support for these objects from here. Support for the latest Azure SQL DB and SQL Server 2016 features is only available in the Preview for VS2013 at present, whereas for VS2015 the support was shipped in VS2015 Update 2. Once SQL Server 2016 goes GA (June 1, 2016) an RTM update will be pushed through the Visual Studio 2013 Extensions and Updates channel containing this support. That will ensure you get monthly updates with the latest changes again.
Note that even with the latest bits, if you open the file itself you'll get an issue with the Intellisense parser. Building the project will work fine but on opening a document you will see the errors appear for that specific document. Note that the same issue occurs in SSMS when coding this into a query window. This is because the Intellisense parser is separate from the core build system. The fix for this is in progress and will land in a post-SQL Server 2016 update (likely late June - July timeframe).
Disclosure: I work on the SQL Server tools team.
I am trying to import the exported BACPAC from an SQL Azure (v12) database into a local SQL Server 2012 instance, but I keep getting the error below. I have tried installing the DAC and SSDT updates linked from this blog post, but it's not helping.
How can I fix this?
TITLE: Microsoft SQL Server Management Studio
------------------------------
Count not load schema model from package. (Microsoft.SqlServer.Dac)
------------------------------
ADDITIONAL INFORMATION:
Internal Error. The database platform service with type Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider is not valid. You must make sure the service is loaded, or you must provide the full type name of a valid database platform service. (Microsoft.Data.Tools.Schema.Sql)
------------------------------
BUTTONS:
OK
------------------------------
Updated: The new SQL Server Management Studio Preview is the best way to Import to Azure SQL DB. It has support for all the latest Azure SQL DB features and validations. In addition it has a standalone web installer that is automatically updated each month as new features become available. Given comments below mentioning the difficulty of installing a CU update, this would be a simpler & quicker solution to the problem.
Original Answer:
If you are using SQL Server Management Studio to perform the Import, you must have SSMS 2014 CU5 or CU6 installed. Information on installing CU6 is available here. The error shown in your question indicates you're using an older version of SSMS.
**Update: **
In response to Martin's answer below, I'd like to clarify 2 things.
SSMS for SQL Server 2014 is the only version of SSMS with full support of the new Azure SQL DB v12 features, notably Import/Export against this target. This is because v12 has (almost) feature parity with SQL Server 2014 and older versions of the tooling do not have support for this. Note that SSMS 2014 is fully backwards compatible with SQL Server 2005 and up.
There was a separate, temporary issue that caused problems with databases upgraded Azure SQL DB v12. This has been resolved and the correct place to find information about solving this are in section C3 of the Plan and Prepare to Upgrade page. In summary if you've exported a bacpac that is failing to import due to this issue you can download the latest DacFramework.msi from here to fix this issue in SSMS.
Full disclosure: I work on the SQL Server tools team.
To fix import error with [sys].[script_deployment_databases] from exported V12 Database you have to install:
CU13
Microsoft SQL Server Data-Tier Application Framework (February 2015) (you must install BOTH the x64 and x86 versions).
EDIT: CU13 is not necessary, just try second link first!
Install the following and it will work!
1) Have you installed Cumulative Update 5 for SQL Server Management Studio 2014. http://support2.microsoft.com/kb/3011055
2) Microsoft SQL Server Data-Tier Application Framework (February 2015) (you must install BOTH the x64 and x86 versions). http://www.microsoft.com/en-us/download/details.aspx?id=45886
I had the same problem with my dataabse backup from SQL Azure (v12).
I've installed Microsoft® SQL Server® Data-Tier Application Framework (February 2015) (in order to work correctly you will need install BOTH the x64 and x86 versions).
First I've installed x64 version and tried to restore the DB - but it didn't work. After that I've installed x86 version and I could successfully restore the database.
My SQL Server version: Microsoft SQL Server 2014 - 12.0.2269.0 (X64). OS: Windows 10 x64 build 10240.
Tnanks.
BacPac restore from Azure DB fails after installing latest SQL Server Management Studio 2016 Preview. Solution was to set "Contained Database Authentication" = 1 for my local SQL DB instance. Read about solution here or run this script on your local instance:
USE master
GO
RECONFIGURE
GO
sp_configure 'CONTAINED DATABASE AUTHENTICATION', 1
I was using wrong SqlPackage.exe path.
Does not work:
C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\SqlPackage.exe
Works:
C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin\SqlPackage.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\SqlPackage.exe
I'm having the same issue.
Installing Cumulative update package 6 as suggested here helps to avoid the first bug but just to get stuck in the next one.
Related to this topic:
SQL Azure import of bacpac does not work after upgrade to v12
it's a bug Microsoft has no fix or workaround yet.
Edit: SQL Management Studio 2014 is required to restore (2012 doesn't work)
If there's one, I think the thread will be updated.
Edit: In the above mentioned link you now can find a workaround: You need to create a copy of your V12 database. This copy can be exported and reimported on your local sql server 2014.
Just updating the tools doesn't help.
I'm using version 11.0.2100.60 and had the same issue. Installed Microsoft® SQL Server® Data-Tier Application Framework (February 2015). All worked fine after that.
I installed VS2012, SSME 2012 with localdb, and I discovered that I have 2 servers that I can connect to: (localDB)\v11.0 and (localDB)\Projects.
Which of them do I have to use for execising, what are them both for?
I know I am bit late. But I am facing the same question now and found the answer. Thought I should share the Answer:
(localdb)\Projects is the SQL Server Express LocalDB instance which is used by SQL Server Data Tools by default to host the sandbox databases created for your database projects (*.sqlproj) to enable F5 deployment and debugging.
(localdb)\v11.0 is the generic SQL Server Express LocalDb instance which gets created when LocalDB is installed, and this is also used by other Visual Studio projects like the ASP.NET projects.
See http://msdn.microsoft.com/en-us/library/hh510202.aspx for more information on LocalDB
Update
Starting from EntityFramework 5.0, the default sql server is the your localdb\vxx.x instance now.
This explains the difference and some issues to watch out for
http://aeronaught.wordpress.com/2012/11/22/vs2012-localdb-v11-1-v11-0-automatic-instance-horror/
Not sure on the difference but you should be using
(localdb)\v11.0