小编Ata*_*rio的帖子

我在C#工作,并且我一直非常松懈地使用using块来声明实现的对象IDisposable,这显然是你应该做的.但是,我没有看到一种简单的方法来了解我何时滑倒.Visual Studio似乎没有以任何方式表明这一点(我只是错过了什么？).我每次申报任何东西时都应该检查帮助,然后逐渐建立一个百科全书式的记忆,对象是哪些,哪些不是一次性的？似乎没有必要,痛苦和容易出错.

如何你处理这个问题？

编辑:

看一下相关问题的侧边栏,我发现了另一个问题,它明确表示Dispose()应该被对象的终结器调用.因此,即使你自己也没有自己调用它,它最终会发生,这意味着如果你不使用它就不会有内存泄漏using(这是我认为我一直非常担心的).唯一需要注意的是,垃圾收集器不知道对象作为非托管内容持有多少额外内存,因此无法准确了解通过收集对象将释放多少内存.这将导致垃圾收集器的性能低于平常.

简而言之,如果我错过了,那就不是世界末日了using.我只是希望有些东西会产生至少一个警告.

(偏离主题:为什么链接到另一个问题没有特殊的降价？)

编辑:

好的,好的,别叫吵了.这是超级决斗所有激烈的戏剧性 - 花栗鼠级别的重要打电话Dispose()或我们都会死.

现在.鉴于此,为什么这么容易 - 地狱,为什么甚至允许 - 做错了？你必须尽力去做正确的事.像其他一切一样做它会导致世界末日(显然).封装这么多,是吧？

[偷偷摸摸,反感]

好.这是我尝试运行的内容:

USE tempdb;

SELECT TOP 1000000 IDENTITY(INT, 1, 1) Number
INTO Numbers
FROM sys.objects s1
CROSS JOIN sys.objects s2
CROSS JOIN sys.objects s3
CROSS JOIN sys.objects s4;

这是"让我成为数字表"查询之一.

这是问题所在.如果我在(重新)启动SQL Server服务后立即运行它,则需要永久.不是十分之一,我希望它更快.永远如此,我让它一次又一次地超过两个小时,仍然不得不杀死它.我在想它永远不会回来.通常我的机器上运行它需要两秒钟.

但是,如果我这样做:

USE tempdb;

SELECT TOP 1000000 IDENTITY(INT, 1, 1) Number
INTO Numbers
FROM sys.objects s1
CROSS JOIN sys.objects s2
CROSS JOIN sys.objects s3;

DROP TABLE Numbers;

SELECT TOP 1000000 IDENTITY(INT, 1, 1) Number
INTO Numbers
FROM sys.objects s1
CROSS JOIN sys.objects s2
CROSS JOIN sys.objects s3
CROSS …

我有两种不同的字符串,我在我的代码中传递和使用,两者密切相关,但不应相互混淆.我认为我可以通过让两个只是字符串的类来帮助自己避免错误,但是使用不同的名称以便方法签名(以及通常的类型不兼容)将强制执行两种不同类型字符串的语义含义.与此同时,我不想不得不从重构something = "foo";到something.Value = "foo";中百地方.

首先想到:

private class FirstKind : string { }
private class SecondKind : string { }

我的想法是,如果我有

void MyMethod(FirstKind varOne, SecondKind varTwo) {...}

,然后尝试调用它MyMethod(secondKindVar, firstKindVar);,我得到编译器错误.

我打的墙: string是密封的.

第二个想法:创建泛型KindOf<T>类,除了接受并使用隐式转换运算符吐出值之外什么也不做.像这样:

private class KindOf<T>
{
    public T Value { get; set; }
    public KindOf() { Value = default(T); }
    public KindOf(T val) { Value = val; }
    public static implicit operator T(KindOf<T> kindOf) { return kindOf.Value; }
    public static implicit …

根据我的阅读,所有Windows版本和.NET都是小端.那么为什么偏离微软的SQL Server规范呢？

我的意思是"SQL Server是大端"是这样的:

SELECT CONVERT(VARBINARY, 255);

得到:

0x000000FF

并不是

0xFF000000

类似于.NET的BitConverter.GetBytes()方式.我猜SQL Server可以在内部存储数字作为小端,然后CONVERT由于某种原因只是将其切换.但不管怎样,为什么？

编辑:

刚注意到这个......

DECLARE @q UNIQUEIDENTIFIER = '01234567-89ab-cdef-0123-456789abcdef';
SELECT @q;
SELECT CONVERT(VARBINARY, @q);

给我:

01234567-89AB-CDEF-0123-456789ABCDEF

0x67452301AB89EFCD0123456789ABCDEF

有没有搞错？

我有一个我每周"发布"的数据库,这意味着我发布了一个人们可以开始的备份,并且我发布了一个他们可以用来从上周升级的更新脚本(这样他们就可以尽可能地保留他们当前的数据).当然,此脚本包含大量的DDL的- CREATE TABLE,ALTER TABLE等等.它的基本结构是这样的:

/*

HOW TO USE THIS SCRIPT

1.  Run it against your existing DB
2.  Check whether there were any errors
3.  If there were, issue a rollback by highlighting this:
        ROLLBACK
    and executing it
4.  If there weren't, issue a commit by highlighting this:
        COMMIT
    and executing it
5.  !!! Not doing either of these will leave a transaction open, which will
    probably cause all further queries to time out till you do …