文章标签 ‘SQL’
[转载]支持定位当前页,自定义排序的分页SQL(拒绝动态SQL) – 牟向阳 – 博客园. 1,场景：根据学生编号查询，返回该学生所在班级的所有学生。支持分页、自定义排序及结果集自动定位到查询条件的学生编号所在页。 CREATE PROC [dbo].[Sp_testpagerandsorting] (@GroupID INT, @CurrentId INT, @TimeFrom DATETIME, @TimeTo DATETIME, @OrderBy CHAR(50), @PageSize INT, @CurrentPage INT) AS SET nocount ON BEGIN DECLARE @StartNumber INT, @EndNumber INT, @CurrentIdRowNumber INT, @RecordCount INT, @EndPageIndex INT DECLARE @RowNumberTable TABLE ( rownumber INT IDENTITY (1, 1), id INT ) –step 1: Build sort [...]
目前项目需要点击datagrid的某列后台自动按此列的升降规则排序返回分页的结果集，目前用的是ORM的映射Select不是拼装的SQL语句，于是查了下资料 发觉用如下SQL代码实现自定义排序规则： declare @sort nvarchar(60) declare @order nvarchar(50) set @sort=’Buyer’ set @order=’desc’ if @order=’desc’ begin select buyer from View_StockInto order by case @sort when ‘Buyer’ then Buyer end desc end else begin select buyer from View_StockInto order by case @sort when ‘Buyer’ then Buyer end end
[转载]T-SQL查询进阶—理解SQL Server中的锁 – CareySon – 博客园. 简介 在SQL Server中，每一个查询都会找到最短路径实现自己的目标。如果数据库只接受一个连接一次只执行一个查询。那么查询当然是要多快好省的完成工作。但对于 大多数数据库来说是需要同时处理多个查询的。这些查询并不会像绅士那样排队等待执行，而是会找最短的路径执行。因此，就像十字路口需要一个红绿灯那 样，SQL Server也需要一个红绿灯来告诉查询:什么时候走，什么时候不可以走。这个红绿灯就是锁。 图1.查询可不会像绅士们那样按照次序进行排队 为什么需要锁 在开始谈锁之前，首先要简单了解一下事务和事务的ACID属性。可以参看我之前的一篇关于ACID的文章。 如果你了解了事务之间的影响方式，你就应该知道在数据库中，理论上所有的事务之间应该是完全隔离的。但是实际上，要实现完全隔离的成本实在是太高(必须是 序列化的隔离等级才能完全隔离，这个并发性有点….)。所以，SQL Server默认的Read Commited是一个比较不错的在隔离和并发之间取得平衡的选择。 SQL Server通过锁，就像十字路口的红绿灯那样，告诉所有并发的连接，在同一时刻上，那些资源可以读取，那些资源可以修改。前面说到，查询本身可不是什么 绅士，所以需要被监管。当一个事务需要访问的资源加了其所不兼容的锁，SQL Server会阻塞当前的事务来达成所谓的隔离性。直到其所请求资源上的锁被释放，如图2所示。 图2.SQL Server通过阻塞来实现并发 如何查看锁 了解SQL Server在某一时间点上的加锁情况无疑是学习锁和诊断数据库死锁和性能的有效手段。我们最常用的查看数据库锁的手段不外乎两种: 使用sys.dm_tran_locks这个DMV SQL Server提供了sys.dm_tran_locks这个DMV来查看当前数据库中的锁,前面的图2就是通过这个DMV来查看的. 这里值得注意的是sys.dm_tran_locks这个DMV看到的是在查询时间点的数据库锁的情况，并不包含任何历史锁的记录。可以理解为数据库在查 询时间点加锁情况的快照。sys.dm_tran_locks所包含的信息分为两类，以resource为开头的描述锁所在的资源的信息，另一类以 request开头的信息描述申请的锁本身的信息。如图3所示。更详细的说明可以查看MSDN(http://msdn.microsoft.com/en-us/library/ms190345.aspx) 图3.sys.dm_tran_locks 这个DMV包含的信息比较多，所以通常情况下，我们都会写一些语句来从这个DMV中提取我们所需要的信息。如图4所示。 图4.写语句来提取我们需要的锁信息 使用Profiler来捕捉锁信息 我们可以通过Profiler来捕捉锁和死锁的相关信息，如图5所示。 图5.在Profiler中捕捉锁信息 但默认如果不过滤的话，Profiler所捕捉的锁信息包含SQL Server内部的锁，这对于我们查看锁信息非常不方便，所以往往需要筛选列，如图6所示。 图6.筛选掉数据库锁的信息 所捕捉到的信息如图7所示。 图7.Profiler所捕捉到的信息 锁的粒度 [...]
[转载]使用事务操作SQLite数据库和一些常用的SQL语句 – forrest001 – 博客园. 使用SQLiteDatabase的beginTransaction()方法可以开启 一个事务，程序执行到endTransaction() 方法时会检查事务的标志是否为成功，如果程序执行到endTransaction()之前调用了setTransactionSuccessful() 方法设置事务的标志为成功则提交事务，如果没有调用setTransactionSuccessful() 方法则回滚事务。使用例子如下： SQLiteDatabase db = ….; db.beginTransaction();//开始事务 try { db.execSQL(“insert into person(name, age) values(?,?)”, new Object[]{“传智播客”, 4}); db.execSQL(“update person set name=? where personid=?”, new Object[]{“传智”, 1}); db.setTransactionSuccessful();//调用此方法会在执行到endTransaction() 时提交当前事务，如果不调用此方法会回滚事务 } finally { db.endTransaction();//由事务的标志决定是提交事务，还是回滚事务 } db.close(); 上面两条SQL语句在同一个事务中执行。 一些常见的SQL语句： CREATE TABLE person (_id integer primary key autoincrement, name varchar(20)) SQLite可以解析大部分标准SQL语句，如： [...]
[转载]SQL语句join on 和 where条件 引发的执行顺序解读！！！ – Rouse Law – 博客园. SQL server 2000和SQL Server 2005的各个逻辑步骤的简单描述。 (8)SELECT (9)DISTINCT (11)<Top Num><select list> (1)FROM[left_table] (3)<join_type>JOIN<right_table> (2) ON<join_condition> (4)WHERE<where_condition> (5)GROUPBY<group_by_list> (6)WITH<CUBE | RollUP> (7)HAVING<having_condition> (10)ORDERBY<order_by_list> 逻辑查询处理阶段简介 FROM：对FROM子句中的前两个表执行笛卡尔积（Cartesian product)(交叉联接），生成虚拟表VT1 ON：对VT1应用ON筛选器。只有那些使<join_condition>为真的行才被插入VT2。 OUTER(JOIN)：如 果指定了OUTER JOIN（相对于CROSS JOIN 或(INNERJOIN),保留表（preserved table： 左外部联接把左表标记为保留表，右外部联接把右表标记为保留表，完全外部联接把两个表都标记为保留表）中未找到匹配的行将作为外部行添加到 VT2,生成VT3.如果FROM子句包含两个以上的表，则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3，直到处理完所有的表为止。 WHERE：对VT3应用WHERE筛选器。只有使<where_condition>为true的行才被插入VT4. GROUPBY：按GROUP BY子句中的列列表对VT4中的行分组，生成VT5. CUBE|ROLLUP：把超组(Suppergroups)插入VT5,生成VT6. HAVING：对VT6应用HAVING筛选器。只有使<having_condition>为true的组才会被插入VT7. SELECT：处理SELECT列表，产生VT8. DISTINCT：将重复的行从VT8中移除，产生VT9. ORDERBY：将VT9中的行按ORDER BY 子句中的列列表排序，生成游标（VC10). TOP：从VC10的开始处选择指定数量或比例的行，生成表VT11,并返回调用者。
