Is it possible to obfuscate or scramble a column in SQLServer 2008 R2 without having to use encryption or some highly ineffecient custom made function that does substrings?
Why not use encryption/hashing/encoding in your application and post the results into SQL? That's pretty standard.
If you must do it in SQL Server, you may want to look at using CLR functions within SQL Server.
Not that I know of, encrypt the data coming in and out from the column with a 3rd party app like Java or .NET. If you do it within SQL then the person who steals your backup can decrypt is since he has access to the function
try something like this: obfuscate or encrypt some plain text data in PHP
Something to research a bit further here.
SQL Server 2005+ has the function - ENCRYPTBYKEY and its mate DECRYPTBYKEY
EncryptByKey Params:
key_GUID - the GUID of the key to be used to encrypt the cleartext. uniqueidentifier. This requires you to have a SYMMETRIC KEY open on the server.
cleartex - some text to be encrypted
Returns a varbinary up to 8000.
If you wanted to leverage these methods, you could create a column of type varbinary up to 8000, and save the output here.
I'd be interested to hear comments on real world usages of this function, and any anecdotes on its performance.
Related
I've a MS Access solution accessing to linked tables to SQL Server.
Today it happens that one key filed in a table reached the limit of int.
So my first idea was to change it from int -> bigint but it seems to be not possible as ALTER queries return a couple of errors for.
The second idea was to clone the key field, delete original and make the clone to the new key field.
This worked without problems but now the linked table only show #deleted values for all fields within the table.
It seems that MS Access uses the keys for some relations when it access to the backend.
Maybe somebody know a solution to extend /reset the key without loosing the relation for MS Access?
Thank you
MsAccess has a "long integer" number option in the table design, which has the same size of INT from SQL Server. See below:
https://www.microsoft.com/en-us/microsoft-365/blog/2017/03/06/new-in-access-2016-large-number-bigint-support/
I found this:
"Unfortunately, Access is unable to use BigInt as a primary key. You will most likely need to change this to a long integer. The article below is for an older version of Access, but the info still applies:" (https://answers.microsoft.com/en-us/msoffice/forum/all/linked-table-showing-deleted-in-all-rows-and/d0451a78-08c1-4667-8677-6c61edcebcf1)
So it seems not to be possible to use bigint as key.
I Googled this topic, and this is what I found...
Access CAN handle the BigInt datatype in SQL Server. Only, its handling of this is somewhat faulty.
As far as Access is concerned, BigInt is a STRING. You have to quote it as a string, within Access. Fortunately this isn't a problem on the SQL Server end, as SQL Server is happy with quoted numbers. In-between the two (Access and SQL Server), based on my experience, it appears there is a textual transmission of SQL commands from Access to SQL Server, with some modest dialect translation going on automatically in the background (if anyone knows better, please comment.) BigInt data coming from SQL Server to Access are automatically understood as strings.
https://social.msdn.microsoft.com/Forums/office/en-US/fb6f99ec-2ed7-487b-ba39-0777a0b44d5f/the-bigint-problem?forum=accessdev
MS Access is a 30 year old technology. Do you really want to be using that in 2022 and in the future?
Is it possible to retrieve the actual text from a File Table in SQL Server 2014?
I want to implement some hit-highlighting functionality, but in order to do so, I need to retrieve the actual text in the file I indexed, since the content is in a varbinary column.
If it's not possible, I suppose the only alternative to do this is forgetting about FileTables and implementing an application-side "document reader", so that I'll have real text inside my "file_stream" column instead of the varbinary. Or maybe even defining an UDF that uses iFilters behind some C# code, right?
Please, any advice would be really useful.
Before you do start with your own implementation, take a look at the very similar question:
SQL Server 2012 FTS with Hit-Highlighting?
Also this blog entry from 2012 is still current:
Hit-Highlighting in Full-Text Search
I would take a look at the mentioned HitHighlight function (which is actually a commercial product, ThinkHighlight). Most likely it's not worth the effort to build your own solution. But if you do so - tell me ;)
I've tried using the "EncryptByPassPhrase", which would work for me if I could get the underlying key generated by the passphrase, but nowhere I've found on the internet explains how to do that.
My reading of the relevant EncryptByCert or EncryptByKey is that I have to create and store the keys on the database.
I have a constraint that I must not update the source database, hence I cannot create and store keys on the database.
What I really want is a way using an existing external public key or certificate, to encrypt , and decrypt on a different system.
If you cannot update the source database, I would guess your best option is to use CLR to create a custom stored procedure and then you can use any external library to perform the encryption you require.
There's an example of this here:
http://sachabarbs.wordpress.com/2007/06/06/sql-server-clr-functions/
I am using C# 4.0, VS 2010 MVC 3 and Entity Framework for a web application and using SQL server 2008R2 for data storage. I need to encrypt three columns in one table - two are text columns and one is a date column, to update them and to search for items in those columns using the above technologies.
TDE is not an option.
It seems best practice to perform all the encryption functions on the SQL server however, although there are plenty of examples on how to encrypt the columns as a one off exercise, there is nothing on updating or searching these fields once encrypted.
I can see no other way than to move the encryption and decryption into the application.
All guidance, assistance, pointers and hints are very welcome.
Thank you.
You cannot search encrypted data, by definition. What you can search instead is a hash of the known plain text and deal with possible collisions. For this you need to add additional columns to save the hash of the plain text being encrypted. See Indexing encrypted data for more details and an example.
As for updates I really don't see what the question is. You update the encrypted value with a new encrypted value, just like any other update.
TDE is, by a large margin, a much much better option. Just sayin'.
I am considering migrating to Firebird. To have a "quick start" approach I downloaded the trial of a conversion tool (DBConvert) and tried it.
I just picked up a random tool, this tool doesn't convert procedures, functions and triggers (I don't think it is a limit of the trial since there is not an explicit reference to sp, sf and triggers in the link above).
Anyway by trying that tool I had the message:
The DB cannot be converted
successfully because some FK names are
too long.
This is because in some tables I have FK whose description is > 32 chars.
Is this a real Firebird limit or it is possible to overcome it somehow (of course renaming the FK is an extreme option because it is extra work)?
Anyway how to convert a SQL Server database fully to Firebird? Is there a valid tool? Did someone succeed in a conversion of non trivial databases?
You can use some tools like Interbase Datapump and you can also check this
For size of FK : you have to rename them :(
You can also try to make this with Database Worbench
I doubt you'll be able to just "convert" that all. Firebird/Interbase and Microsoft SQL Server use quite different data types, their SQL language dialect is somewhat different, and so forth.
You could probably get a 60-80% conversion - but the rest will always be manual effort that's needed.
If your conversion fails just because of those FK constraints: drop those in SQL Server before the conversion, and re-create them on the Firebird side after conversion.
Or: drop them in SQL Server and re-create them with shorter names, and then do the conversion.
I know two more tools that might help you in the conversion.
The ESF Database Migration Toolkit
link text
and the DeZign for Databases
link text