no, you can still join on these columns.

yes, if you specifically deny access to a key by a user, otherwise it can be used in the context of the stored procedure.

I despise poorly written code and the reasons are many:

* usually consumes (wastes) precious resources (memory, CPU, I/O)

* exhibits poor concurrency

* poor scalability

* poor documentation

The typical argument I hear for...

If you are granted execute persmission on the Stored Procedures , the keys can be used in them by the TSQL code in the SP but not directly.

Except for sysadmins,...

Only grant access to the symetric keys to those users/roles that absolutely need to decrypt any column. In my opinion that would be the database administrator(s) only.

Grant execute only on...

I have never seen any benchmarks comparing these three. If it were me I would only use SQL native client, if only because of its more robust error reporting and...

Create a temporary tally table and use it, no need for a permanent one.

Native Client is the most recent driver for the newest version of SQL server for those not using .NET data provider classes (legacy code).

In my experience SQLNCLI(10) is a...

A primary key is not needed for log tables or certain staging tables. Often I see people add an identity column to these tables anyway... whether it is needed or...

Tallboy (11/4/2011)

---

Going back to my example above it looks like I will have to add the task id's to the Client table to keep the whole ref integrity correct and...

L' Eomot Inversé (11/4/2011)

---

And yes, doing this is normal practise; but so, regrettably, is using NULL instead of a dummy client id for your own organisation, which says a...

Few things remain...

Tallboy (11/4/2011)

---

.... when you come to look at this field again how do you know if its a client ID or a Task ID?, what is both ID use...

Tallboy (11/4/2011)

---

Hi,

Thats they standrad way of ading non client data to the tbl Client surely this breaks the data integrity of the whoel thing, whne I wan a count of...

This query is full of performance (scalability) issues. The where clause requires the decryption of virtually every encrypted column in your table then serached with "like '% something %' "...