I have two encrypted columns in SQL Server 2016 and I would like to update the values of these 2 columns.
I read on the Microsoft Always Encrypted page that to be able to update an encrypted colum, it "requires at least SQL Server Management Studio version 17 to insert, update, or filter encrypted columns." So I looked at SQL Server Management Studio (SSMS) download page, the current release for production use is v16.5.3. The only v17 I can see is 17.0 RC3 and it has a comment saying "not recommended for production use". Our Operation team is not very willing to use this version since it is not recommended. Our C# code can make changes to these columns, but it is not an easy process to update production source code and we simply want to fix some data in these encrypted columns.
So the question is without SSMS version 17, is there a way to update SQL erver 2016 Encrypted Columns in SSMS?
Update: SSMS v17.0 has released. You should now be able to update encrypted cells.
Unfortunately, the answer to your question is no. Currently only SSMS v17 release candidates support updating cells encrypted using Always Encrypted.
Related
I'm using SQL Server 2016 and SQL Server Management Studio updated to v17.4.
I want to use Always Encrypted to encrypt a column. I tried to run the Always Encrypted wizard as illustrated in a number of places. I right click the database node, choose Tasks and there's supposed to be an option Encrypt Columns, but there isn't.
In the Security folder of the database in Management Studio, there's an option of Always Encrypted Keys, but I want to use the wizard.
How can I get the Encrypt Columns option to be displayed and display the wizard?
I had to download Sql Server 2016 SP1 and that solved the problem. I got the direction from a different question, SQL2016 Not able to create Column Master Key, in seth flowers answer.
I have a seemingly straight forward project, which unexpectedly faces many obstacles.
I need to move backend data of the existing Access 2016 application from Access to SQL Server 2016.
The challenges I face are:
The simplest and recommended way to migrate Access to SQL Server is using Microsoft SQL Server Assistant (SSMA) for Access. The problem is that my Access is 32-bit Click-to-Run edition. Because the target is SQL Server 2016, I should use SSMA for Access v.7.6.0, which is available only in 64-bit. To use it, I need to install 64-bit Access Runtime, which could not be installed, because per the error message “Windows Installer and Click-to-Run editions of Office programs don't get along”. The earlier version of SSMA for Access 6.0 comes in 32-bit and connects to Access fine, but could not connect to SQL Server 2016, as 2014 is the latest version it supports. Ignoring the warning and forcing the connection to SQL Server 2016 causes error collecting data… Thus, I could not use SSMA.
I was able to migrate the data from Access to SQL Server using SSIS. Now, my challenge is to repoint existing Access tables to their SQL Server copies. I was trying link, but it appears that existing Access tables could be linked only to the file system data source. If I try to make link from the SQL Server side, I could only create new linked tables, which do not do me much good as I am trying to avoid massive changes in the application. Could it be that I am missing something simple here?..
Some Access tables have columns of attachment data type. SSIS doesn’t handle attachment data type correctly. To the best of my knowledge, neither does SSMA. So, when I get to link Access tables to SQL Server, I would probably need to write some code to move attachments from the backup Access database to SQL Server. Is there some other an easier solution?
Any suggestions are greatly appreciated.
That is correct. It is a mess. You can use another (virtual) machine with a clean 64-bit Access install.
Delete the current tables in the frontend and link the SQL Server tables. They may be given a "dbo_" prefix which you can remove by renaming the tables.
This is a rewrite. Attachment fields are not supported in SQL Server. Neither are other fancy features like lookup fields and multivalue fields.
Here's my current dilemma: I need to migrate the database, including the data, from SQL server version 13 to version 12. The source is on an Azure box and the destination is on my local box. I can't install SQL server 2016 on my local box; that isn't an option. How do I do this?
I would recommend you to use SQL Database Migration Wizard
Can you try using SqlPackage to Export the Azure database?
I've recently done the opposite of you, exporting SQL Server 2012 databases to Azure SQL V12. I used a combination of SqlPackage and Visual Studio with SQL Server Data Tools.
Basically I made a SQL Project based on the source databases (SQL Server 2012 hosted), set the target platform to Microsoft Azure SQL V12 and fixed any errors and warnings that wasn't supported in Azure SQL V12.
I then did a schema compare between the source database and the SQL Project. With this I generated a script which I ran against a copy of the source database.
Lastly I used SqlPackage to make a .bacpac from the database I ran the script against, which I could then deploy to Azure.
If you do the opposite maybe it'll work. It is important that when working with Azure SQL that you have updated software.
It seems that the answer is in insert scripts, which I didn't realize was a thing. There's good information at How to generate an INSERT script for an existing SQL Server table that includes all stored rows?
Edit: Another answer says NOT to generate INSERT scripts to copy all the data from a DB. I tried it and it seemed to fail because of some truncation in the script itself (it ended up being over 11 GB). A developer I'm working with suggested the bcp utility (documentation at this link), which I have not yet tried.
I know that you can't (at least not easily) restore a SQL Server 2012 backup on SQL Server 2008. But how does it work for SQL Server 2014 to SQL Server 2012 ?
On database level there is the property to adjust the compatibility mode to any other SQL Server version.
How does this helps or work ? Will it only disallow the features from 2014?
To be honest I already tried to restore a backup, but 2012 didn't recognize the datafile, so I couldn't click ok Button to start the restore procedure.
Did I miss some important option ?
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version of SQL Server down to an older version - the internal file structures are just too different to support backwards compatibility. This is still true in SQL Server 2014 - you cannot restore a 2014 backup on anything other than another 2014 box (or something newer).
You can either get around this problem by
using the same version of SQL Server on all your machines - then you can easily backup/restore databases between instances
otherwise you can create the database scripts for both structure (tables, view, stored procedures etc.) and for contents (the actual data contained in the tables) either in SQL Server Management Studio (Tasks > Generate Scripts) or using a third-party tool
or you can use a third-party tool like Red-Gate's SQL Compare and SQL Data Compare to do "diffing" between your source and target, generate update scripts from those differences, and then execute those scripts on the target platform; this works across different SQL Server versions.
The compatibility mode setting just controls what T-SQL features are available to you - which can help to prevent accidentally using new features not available in other servers. But it does NOT change the internal file format for the .mdf files - this is NOT a solution for that particular problem - there is no solution for restoring a backup from a newer version of SQL Server on an older instance.
Sure it's possible... use Export Wizard in source option use SQL SERVER NATIVE CLIENT 11, later your source server ex.192.168.100.65\SQLEXPRESS next step select your new destination server ex.192.168.100.65\SQL2014
Just be sure to be using correct instance and connect each other
Just pay attention in Stored procs must be recompiled
My company is planning to migrate it's intranet/internet based ERP to the latest form of MS SQL Database available.
Presently we are using SQL Server 2000 Professional.
And we are planning to shift to SQL Server 2008 Web edition.
Please tell me whether this is the right step and whether it is feasible or not.
Thank you in advance.
"Please tell me whether this is the right step " - that's something you and your company need to decide.
It is feasible, and in the majority of cases straight forward.
Your first step should be to run the Microsoft SQL Server 2008 Upgrade Advisor
Microsoft SQL Server 2008 R2 Feature Pack contains the Microsoft SQL Server 2008 R2 Upgrade Advisor
Formulate and test a rollback plan
Determine your upgrade window and acceptable downtime.
Ensure database consistency: Run DBCC CHECKDB on databases to be upgraded to ensure that they are in a consistent state before performing the upgrade.
Back up all important files: Back up all SQL Server databases from the instance to be upgraded (including master, model and msdb), data and transaction log files, as well as any application files, script files, extract files, etc. so that you can completely restore them in the event of a failure.
It's both feasible and easy. The path from one version of SQL Server to another is usually pretty simple. Do you have any special stored procedures or reports generated in SQL Server that need to be rewritten/re-imported?
As far as right step - the question is, Why? If it's working, do you really need to mess with it?
If it's for intranet (some app for your internal usage) then consider using SQL 2008 Express edition. It's free and you can use it as an instance running along the full 2000 version. That way you will have some extra features from the full version.
But you have to know that applications running on SQL 2000 may not work on 2008 and they are even more probable not to work on 2008 R2.