1. 在64位机上用VS2010开发，在这里下载SQLite安装包
2. 下载的安装包里，有一个最重要的system.data.sqlite.dll文件，必须要选择复制到本地，也就是与所完成的EXE文件在同一目录下，或者在VS中选择Copy Local为True： 
3. 目标机必须安装MS VC++ 2010 redistributable package。在此下载
4. 如果工作机和目标机的平台不一样（一个是64位，一个是32位），则把2中的Copy Local回到False，按照以下结构布置文件：
<bin\>YourProgram.EXE
<bin\>System.Data.SQLite.DLL
<bin\x64\>SQLite.Interop.dll
<bin\x86\>SQLite.Interop.dll
其中<bin\>是工作目录，YourProgram.EXE是你自己的EXE程序，那2个SQLite.Interop.dll分别是对应64位与32位的执行DLL文件，而那个System.Data.SQLite.DLL则是一个小型DLL，与第2点中的DLL是不同的文件，这个才200多K，而那个有1M多。
这3个文件可以在这里下载：SQLiteBinaryforx86Andx64.zip
1. 先using System.Data.SqlClient;
2. 在函数中,定义SqlConnection:
- SqlConnection conn = new SqlConnection("...连接字串...");
3. 紧接着,定义SqlCommand来执行SQL语句:
- string s = "select * from tableA";
- SqlCommand q = new SqlCommand(s, conn);
- conn.Open();
4. 定义SqlDataReader来接受返回的记录,除了用ExecuteReader返回SqlDataReader,还有ExecuteNonQuery,ExecuteScalar返回简单值的应用,详见MSDN.用完以后,记得Close这个SqlDataReader,不然以后使用SqlCommand时会有麻烦.
- SqlDataReader r = q.ExecuteReader();
- if (r.Read())
- {
- Response.Write(r[0].ToString().Trim());
- }
- r.Close();
5.如果需要再次查询,可以使用同一个SqlCommand,只要记得前面关闭了SqlDataReader,使SqlCommand重获自由.
- q.CommandText = "update tableA set ColA='A' where ColB='B'";
- q.ExecuteNonQuery();
6. 全部用完以后,关闭SqlConnection
- conn.Close();
SQL Server 2005：SQL代码安全之权限
一、 SQLCLR权限集级别
当你使用CREATE ASSEMBLY语句把一个程序集加载到一个数据库中时，SQL Server提供了三种权限集级别：SAFE，EXTERNAL_ACCESS和UNSAFE。这些权限集形成所示的AppDomain策略级别。
下面是一个典型的语句，它实现安装位于FileLoader.dll文件内的一个程序集，并且赋予它EXTERNAL_ACCESS权限集。
- CREATE ASSEMBLY FileAccess
- FROM 'E:FileLoader.dll'
- WITH PERMISSION_SET = EXTERNAL_ACCESS
- GO
在代码执行时，每一种权限集级别都授予该代码一组不同的CAS许可权集。下面让我们开始讨论在每一级上授予的特定许可权。
(1) SAFE
SAFE是默认的权限集。它仅授予足够的许可权来执行代码，实现不要求存取外部资源的内部计算以及存取在宿主SQL Server实例中的数据和对象。注意，SAFE代码不能存取外部的资源，因此它不能读取或写磁盘文件，不能存取任何其它SQL Server实例，或读取或写注册表。而且，该代码也必须被检验为类型安全的，这将有助于避免各种包括缓冲区溢出在内的攻击。
SAFE代码是更可靠和安全的SQLCLR代码。它能够实现用T-SQL书写的代码在数据库和服务器实例内所能实现的几乎一样的功能。它能够授予如表格1所列举的CAS许可权。从表格1中可见，该代码能够运行和读取宿主SQL Server实例中的对象和数据-借助于一种特定形式的ADO.NET连接串，或者是"context connection=true"或者是"context connection=yes"来实现。任何其它连接串都可能会导致某种安全异常。
| 权限 | 类型 | 限制 |
| SecurityPermission | 受限制 | 执行 |
| SqlClientPermission | 受限制 | 不能是空口令，只能使用上下文连接串 |
授予给一个程序集的结果权限集是列举于表格1中的许可权权限集与来自企业、机器和用户权限集的交集。因为这些级别默认会拥有所有的许可权，所以程序集仅接受列举于表格1中的权限。注意，请确保你一定要理解这些权限。
(2) EXTERNAL_ACCESS
与SAFE相比，EXTERNAL_ACCESS权限集允许有限制地存取存在于SQL Server实例外部的资源-包括磁盘文件，在其它SQL Server实例中的数据和对象，环境变量和注册表的一些部分。存取这些其它资源通常是在SQL Server服务帐户的安全上下文中进行的，但是，该代码能够模拟其它用户进行存取。这个级别授予列举于表格2中的许可权。
| 权限 | 类型 | 限制 |
| EnviromentPermission | 不受限制 | - |
| FileIOPermission | 不受限制 | - |
| RegistryPermission | 受限制 | 仅能以读方式存取HKEY_CLASSES_ROOT，HKEY_LOCAL_MACHINE，HKEY_CURRENT_USER，HKEY_CURRENT_CONFIG和HKEY_USER |
| SecurityPermission | 受限制 | Assertion，Execution，SerializationFormatter，ControlPrincipal |
| KeyContainerPermission | 不受限制 | - |
| SqlClientPermission | 不受限制 | - |
| EventLogPermission | 受限制 | 仅限于本地主机且仅限于系统管理员 |
| DnsPermission | 不受限制 | - |
| SocketPermission | 受限制 | 仅限于IP地址 |
| WebPermission | 受限制 | 仅能通过HTTP存取本地主机 |
| SmtpPermission | 受限制 | 仅能进行连接存取 |
| DistributedTransactionPermission | 不受限制 | - |
| NetworkInformationPermission | 受限制 | 仅能通过Ping方式存取 |
| StorePermission | 不受限制 | - |
上面不受限制的FileIOPermission可能看起来有点令人担心，因为，它意味着，从CLR的角度来看，代码能存取磁盘上的任何位置。但是切记，该代码仍然运行于本地服务帐户的操作系统安全限制下。因此如果该帐户不能存取一个文件的话，那么SQLCLR代码也不能存取。
典型地，本地服务帐户是一种具有极强权限的帐户，因此存在滥用的可能性。为此，我们一般把对这些程序集的存取权限仅授予那些具有服务帐户信任度的登录并且不使用本地系统帐户作为SQL Server的服务帐户。
值得注意的是，借助于EXTERNAL_ACCESS权限集，你可以使用一个更传统型的ADO.NET连接串来连接到在同一个SQL Server实例（SQLCLR代码在其中运行）中的一个数据库。这需要SqlClientPermission以便你能够使用一个除了"上下文连接"串以外的连接-用以读取当前实例中的数据，指定通常的服务器命名，凭证，等等。然而，我也无法找到为什么你要这样做的理由，但是既然我们可以进行选择，也是一件好事，对吗？
(3) UNSAFE
这个UNSAFE权限集是赋予所有权限的SQLCLR等价物，在这种情况下，CLR挂起所有的许可权检查。它接受单个的不受限制的SecurityPermission权限，这是CLR的授予所有权限的方式。
潜在地，一个UNSAFE程序集能够完成各种"危险性"的动作，因为它属于内在地被信任的代码。例如，它能调用非托管代码，例如COM组件和原始Win32 API。它还受限于服务帐户的操作系统许可权，但是CLR不会限制它存取任何资源的能力。
因为UNSAFE是如此的不安全，所以，只有一个sysadmin能够创建这种类型的程序集。
二、 访问外部资源
因为访问外部资源需要与操作系统进行交互，所以，当代码尝试存取外部的资源时，存在多种要遵守的规则。
对于SAFE代码来说，这种规则是简单的：如果它试图存取一个外部的资源，那么存取将被否认并且它引发一个异常。就是这些。
对于EXTERNAL_ACCESS和UNSAFE的情况，则复杂些：
规则1:如果代码在一个SQL Server登录的安全上下文下执行（也就是说，还没有被映射到一个Windows用户或组），那么存取将被禁止并且引发一个异常。一个SQL登录并不拥有SQL Server外的任何许可权，因此这是很重要的。
规则2:如果代码在一个被映射到一个Windows登录的登录下执行，那么进行外部存取的执行上下文就是该登录的执行上下文。如果该用户能够存取Windows中的资源，那么该代码成功。如果不是，存取被否认并且引发一个异常。
规则3:如果调用者不是原始的调用者（已经进行了一个执行上下文切换)，那么存取被否认并且引发一个异常。
很多地方对EXECUTE AS 的三个参数CALLER, SELF, OWNER的说明不直观.
这里简单地举例说明: A需要拥有一个过程P1用来对表T1进行操作, B建立了这个过程,给C赋与了EXECUTE权限来运行这个STORED PROCEDURE
EXECUTE AS CALLER: 查看C(运行P1的人)有没有权限读T1
EXECUTE AS SELF: 查看B(P1的创建者)有没有权限读T1
EXECUTE AS OWNER: 查看A有没有权限读T1,以后换成D拥有P1就查看D有没有权限读T1
都是用于全文搜索用,这两者的区别是:
1. CONTAINSTABLE功能强,参数组合可以表达几乎任意情况,而FREETEXTTABLE功能较弱,一般用于固定的字符串搜索
2. 相较于第一条所带来的结果,CONTAINSTABLE耗费的资源多,速度慢,而FREETEXTTABLE消耗的资源少
3. CONTAINSTABLE用于精确搜索,FREETEXTTABLE会查找出相近的结果,比如搜索SWIM会找到SWAM
--对这一点的补充: 用CONTAINSTALBE时,加入FORMS OF INFLECTIONAL参数也可以找出单词的对应变形(如过去式,复数等),但是不会对单词的同意词等进行扩展搜索,而FREETEXTTABLE就可以搜索到近义词的相关内容
暂时只找到这些区别
