HI There,
I was wondering how I encrypt the data I have in my SQL sevrer database? is
there some built in tool that will do this? if there is can someone provide
me with a code snippet to get me started?
SeanSean,
Generally you will be required to write extended stored procedures that
calls on CryptoAPIs for this, as SQL Server encrypts at the packet level
when you setup your network libraries with encryption turn on either using
SSL or multiprotocol. I don't know of samples that I can supply you with
but I believe companies such as Protegrity has some sort of solution, you
might like visiting their web site and search on the internet for some
others. I'm not sure if the next release of SQL Server, Yukon, will have
this built in, but because it can call into the Cryptography namespace in
the CLR, it may make your life a little easier. Another solution is to use
Windows encrypted file system (EFS) and encrypt your entire database that
way although this might not be as granular as you want it to be.
I hope this helps.
Regards
James|||Have a look at:
Whamware.Crypt - www.whamware.com
dbEncrypt - www.appsecinc.com
Encryptionizer for SQL Server - www.netlib.com
Tom
"sean" wrote:
> HI There,
> I was wondering how I encrypt the data I have in my SQL sevrer database? i
s
> there some built in tool that will do this? if there is can someone provid
e
> me with a code snippet to get me started?
> ...|||I can also recommend XP_Crypt from www.activecrypt.com cheap, fast and very
easy to use, they also sell a great activeX component so you can easily encr
ypt in your front end app and decrypt in the database etc..
nntp://news.microsoft.com/microsoft.public.sqlserver.security/ >
Have a look at:
Whamware.Crypt - www.whamware.com
dbEncrypt - www.appsecinc.com
Encryptionizer for SQL Server - www.netlib.com
Tom
"sean" wrote:
> HI There,
> I was wondering how I encrypt the data I have in my SQL sevrer database? i
s
> there some built in tool that will do this? if there is can someone provid
e
> me with a code snippet to get me started?
> ...
[microsoft.public.sqlserver.security > ]
Showing posts with label built. Show all posts
Showing posts with label built. Show all posts
Sunday, March 25, 2012
Wednesday, March 21, 2012
Data Dictionary project
We have several databases on SQL 2005 which were built seperately. Ive
been asked to come up with a plan for making sure that data elements are
consistent across all of them, and conform to an outside standard
definition which I have a document for. Ive also been asked to make it
easy for any changes in the external definition to be quickly
transferred to all databases. e.g. If the field for Surname changes to
Varchar(55) we should eb able to change it on all databases without
hunting around for places it occurs.
One idea Ive had is to create our own internal set of User Defined Data
Types matching the external dictionary. But ive then got to somehow map
this to all our databases and change them.
Has anyone out there been involved in anything similar or have any ideas?
tia, Matt"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
RedGate software's SQLCompare application does database schema comparisons
and helps keep schemas in sync. Another option is to script out all your
changes ahead of time, apply strict QA and source control policies to them,
and make sure you apply any change scripts to all databases as necessary
(probably a good idea if you're not doing it already anyway). After all, in
a properly normalized database how many different places does Surname
actually occur? (My guess would be once, maybe twice if you have some sort
of pre-load "work table" in place). I'm not too big a fan of the old-style
User-Defined Types, but to each his/her own...|||> If the field for Surname changes to Varchar(55) we should eb able to
> change it on all databases without hunting around for places it occu
I wouldn't use user-defined datatypes for this requirement. Although they
may facilitate a standard definition for types don't change, UDTs complicate
changes to the type after implementation.
Most data modeling tools have features that allow you to address your
dictionary requirements and create change scripts as well. You can also
store dictionary meta-data using extended properties. Also, VS 2005 Team
Edition for Database Professionals (currently in beta) provides refactoring
features and related tools.
Hope this helps.
Dan Guzman
SQL Server MVP
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
> tia, Matt
been asked to come up with a plan for making sure that data elements are
consistent across all of them, and conform to an outside standard
definition which I have a document for. Ive also been asked to make it
easy for any changes in the external definition to be quickly
transferred to all databases. e.g. If the field for Surname changes to
Varchar(55) we should eb able to change it on all databases without
hunting around for places it occurs.
One idea Ive had is to create our own internal set of User Defined Data
Types matching the external dictionary. But ive then got to somehow map
this to all our databases and change them.
Has anyone out there been involved in anything similar or have any ideas?
tia, Matt"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
RedGate software's SQLCompare application does database schema comparisons
and helps keep schemas in sync. Another option is to script out all your
changes ahead of time, apply strict QA and source control policies to them,
and make sure you apply any change scripts to all databases as necessary
(probably a good idea if you're not doing it already anyway). After all, in
a properly normalized database how many different places does Surname
actually occur? (My guess would be once, maybe twice if you have some sort
of pre-load "work table" in place). I'm not too big a fan of the old-style
User-Defined Types, but to each his/her own...|||> If the field for Surname changes to Varchar(55) we should eb able to
> change it on all databases without hunting around for places it occu
I wouldn't use user-defined datatypes for this requirement. Although they
may facilitate a standard definition for types don't change, UDTs complicate
changes to the type after implementation.
Most data modeling tools have features that allow you to address your
dictionary requirements and create change scripts as well. You can also
store dictionary meta-data using extended properties. Also, VS 2005 Team
Edition for Database Professionals (currently in beta) provides refactoring
features and related tools.
Hope this helps.
Dan Guzman
SQL Server MVP
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
> tia, Matt
Data Dictionary project
We have several databases on SQL 2005 which were built seperately. Ive
been asked to come up with a plan for making sure that data elements are
consistent across all of them, and conform to an outside standard
definition which I have a document for. Ive also been asked to make it
easy for any changes in the external definition to be quickly
transferred to all databases. e.g. If the field for Surname changes to
Varchar(55) we should eb able to change it on all databases without
hunting around for places it occurs.
One idea Ive had is to create our own internal set of User Defined Data
Types matching the external dictionary. But ive then got to somehow map
this to all our databases and change them.
Has anyone out there been involved in anything similar or have any ideas?
tia, Matt
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
RedGate software's SQLCompare application does database schema comparisons
and helps keep schemas in sync. Another option is to script out all your
changes ahead of time, apply strict QA and source control policies to them,
and make sure you apply any change scripts to all databases as necessary
(probably a good idea if you're not doing it already anyway). After all, in
a properly normalized database how many different places does Surname
actually occur? (My guess would be once, maybe twice if you have some sort
of pre-load "work table" in place). I'm not too big a fan of the old-style
User-Defined Types, but to each his/her own...
|||> If the field for Surname changes to Varchar(55) we should eb able to
> change it on all databases without hunting around for places it occu
I wouldn't use user-defined datatypes for this requirement. Although they
may facilitate a standard definition for types don't change, UDTs complicate
changes to the type after implementation.
Most data modeling tools have features that allow you to address your
dictionary requirements and create change scripts as well. You can also
store dictionary meta-data using extended properties. Also, VS 2005 Team
Edition for Database Professionals (currently in beta) provides refactoring
features and related tools.
Hope this helps.
Dan Guzman
SQL Server MVP
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
> tia, Matt
been asked to come up with a plan for making sure that data elements are
consistent across all of them, and conform to an outside standard
definition which I have a document for. Ive also been asked to make it
easy for any changes in the external definition to be quickly
transferred to all databases. e.g. If the field for Surname changes to
Varchar(55) we should eb able to change it on all databases without
hunting around for places it occurs.
One idea Ive had is to create our own internal set of User Defined Data
Types matching the external dictionary. But ive then got to somehow map
this to all our databases and change them.
Has anyone out there been involved in anything similar or have any ideas?
tia, Matt
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
RedGate software's SQLCompare application does database schema comparisons
and helps keep schemas in sync. Another option is to script out all your
changes ahead of time, apply strict QA and source control policies to them,
and make sure you apply any change scripts to all databases as necessary
(probably a good idea if you're not doing it already anyway). After all, in
a properly normalized database how many different places does Surname
actually occur? (My guess would be once, maybe twice if you have some sort
of pre-load "work table" in place). I'm not too big a fan of the old-style
User-Defined Types, but to each his/her own...
|||> If the field for Surname changes to Varchar(55) we should eb able to
> change it on all databases without hunting around for places it occu
I wouldn't use user-defined datatypes for this requirement. Although they
may facilitate a standard definition for types don't change, UDTs complicate
changes to the type after implementation.
Most data modeling tools have features that allow you to address your
dictionary requirements and create change scripts as well. You can also
store dictionary meta-data using extended properties. Also, VS 2005 Team
Edition for Database Professionals (currently in beta) provides refactoring
features and related tools.
Hope this helps.
Dan Guzman
SQL Server MVP
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
> tia, Matt
Data Dictionary project
We have several databases on SQL 2005 which were built seperately. Ive
been asked to come up with a plan for making sure that data elements are
consistent across all of them, and conform to an outside standard
definition which I have a document for. Ive also been asked to make it
easy for any changes in the external definition to be quickly
transferred to all databases. e.g. If the field for Surname changes to
Varchar(55) we should eb able to change it on all databases without
hunting around for places it occurs.
One idea Ive had is to create our own internal set of User Defined Data
Types matching the external dictionary. But ive then got to somehow map
this to all our databases and change them.
Has anyone out there been involved in anything similar or have any ideas?
tia, Matt"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
RedGate software's SQLCompare application does database schema comparisons
and helps keep schemas in sync. Another option is to script out all your
changes ahead of time, apply strict QA and source control policies to them,
and make sure you apply any change scripts to all databases as necessary
(probably a good idea if you're not doing it already anyway). After all, in
a properly normalized database how many different places does Surname
actually occur? (My guess would be once, maybe twice if you have some sort
of pre-load "work table" in place). I'm not too big a fan of the old-style
User-Defined Types, but to each his/her own...|||> If the field for Surname changes to Varchar(55) we should eb able to
> change it on all databases without hunting around for places it occu
I wouldn't use user-defined datatypes for this requirement. Although they
may facilitate a standard definition for types don't change, UDTs complicate
changes to the type after implementation.
Most data modeling tools have features that allow you to address your
dictionary requirements and create change scripts as well. You can also
store dictionary meta-data using extended properties. Also, VS 2005 Team
Edition for Database Professionals (currently in beta) provides refactoring
features and related tools.
Hope this helps.
Dan Guzman
SQL Server MVP
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
> tia, Mattsql
been asked to come up with a plan for making sure that data elements are
consistent across all of them, and conform to an outside standard
definition which I have a document for. Ive also been asked to make it
easy for any changes in the external definition to be quickly
transferred to all databases. e.g. If the field for Surname changes to
Varchar(55) we should eb able to change it on all databases without
hunting around for places it occurs.
One idea Ive had is to create our own internal set of User Defined Data
Types matching the external dictionary. But ive then got to somehow map
this to all our databases and change them.
Has anyone out there been involved in anything similar or have any ideas?
tia, Matt"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
RedGate software's SQLCompare application does database schema comparisons
and helps keep schemas in sync. Another option is to script out all your
changes ahead of time, apply strict QA and source control policies to them,
and make sure you apply any change scripts to all databases as necessary
(probably a good idea if you're not doing it already anyway). After all, in
a properly normalized database how many different places does Surname
actually occur? (My guess would be once, maybe twice if you have some sort
of pre-load "work table" in place). I'm not too big a fan of the old-style
User-Defined Types, but to each his/her own...|||> If the field for Surname changes to Varchar(55) we should eb able to
> change it on all databases without hunting around for places it occu
I wouldn't use user-defined datatypes for this requirement. Although they
may facilitate a standard definition for types don't change, UDTs complicate
changes to the type after implementation.
Most data modeling tools have features that allow you to address your
dictionary requirements and create change scripts as well. You can also
store dictionary meta-data using extended properties. Also, VS 2005 Team
Edition for Database Professionals (currently in beta) provides refactoring
features and related tools.
Hope this helps.
Dan Guzman
SQL Server MVP
"Matt" <ma77g@.clara.co.uk> wrote in message
news:1162363143.30942.0@.iris.uk.clara.net...
> We have several databases on SQL 2005 which were built seperately. Ive
> been asked to come up with a plan for making sure that data elements are
> consistent across all of them, and conform to an outside standard
> definition which I have a document for. Ive also been asked to make it
> easy for any changes in the external definition to be quickly transferred
> to all databases. e.g. If the field for Surname changes to Varchar(55) we
> should eb able to change it on all databases without hunting around for
> places it occurs.
> One idea Ive had is to create our own internal set of User Defined Data
> Types matching the external dictionary. But ive then got to somehow map
> this to all our databases and change them.
> Has anyone out there been involved in anything similar or have any ideas?
> tia, Mattsql
Saturday, February 25, 2012
Data access method
I have built a WM5 SQLce2005 application using, primarily, table adapters which sparked a discussion whether it is more effiecent to use table adapters or use SQLce command execution with coding for a device.
Are there any papers / threads or thoughts as to the best access method to use?
The best access method in terms of performance and memory overhead is SQLCeResultset and SQLCEdatareader. There are various performance papers out there, for example: http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032307726&CountryCode=US
Subscribe to:
Posts (Atom)