博客园_UI.net

解决WCF传输大数据量时出错

2012-01-29T10:07:00Z

如不是很较真的应用，把缓冲区设大点就好了，再把序列化对象设大点

首先应将MaxReceivedMessageSize值设大，如：

<basicHttpBinding>
    <binding name="basicBinding" maxReceivedMessageSize="2147483647"></binding>
  </basicHttpBinding>

复制代码

其次，应该将MaxItemsInObjectGraph值设大，如：

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--><behavior name="bcf">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" /> <dataContractSerializer maxItemsInObjectGraph="2147483647" />
</behavior>
</serviceBehaviors>

复制代码

以上为服务器端设置，服务器端和客户端均应设大，客户端设置如下：

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--><behaviors>
<endpointBehaviors>
<behavior name="bhc">
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
</behavior>
</endpointBehaviors>
</behaviors>

复制代码

至此基本已经OK，如果再有问题，可将maxBufferSize、receiveTimeout值设大即可。

本文链接

使用InternetSetCookie

2011-12-08T12:26:00Z

看人品的时候到了!!!!

用HttpRequest POST,GET消息,我们是经常用啦,但将代码读到的COOKIE等信息,赋回浏览器

我们就需要用到InternetSetCookie 这个API了,其实这也没算什么

但今天在SET Cookie发现个,才了解到Cookie还有这方面的细节,我一个做WINFORM的,两年下来接触Cookie,始终未曾注意到....

某高人写下这么一段话,读得断断续续,但大致能明白

格式为：InternetSetCookie(url,NULL,L"CookieTest=ValTest;path=path value;expires=Thu, 01-Jan-1970 00:00:01 GMT");

使用InternetSetCookie删除cookie ms没有官方文档。经过无数次的测试之后发现：

1。删除时一定要传入path参数，而且此参数必须和set是一致.

2。 setcookie是不带path参数则是对当前path起作用（如果url是一个文件的话，MS有问题）

3。不同path值，即使cookie的名字一样也是两个不同的cookie。所以path很重要啊！

还有一个,用WebBrowser Post数据,还可以这么用

string buffer="POST数据"

string Headers = "Content-Type: application/x-www-form-urlencoded";

browser.Navigate(uri, "", Encoding.UTF8.GetBytes(buffer), Headers);

还有另外一个用WebClient的方法,呵....原来控件还是封装了挺多的哈......

本文链接

从System.Environment.TickCount 看最大支持，机子开一开还是要重启一下的

2010-10-14T06:15:00Z

System.Environment.TickCount 最大支持49.2天而已

超过了，系统则返回负数

关于开机时间
看MSDN
// Sample for the Environment.TickCount property.

// TickCount cycles between Int32.MinValue, which is a negative
// number, and Int32.MaxValue once every 49.8 days. This sample
// removes the sign bit to yield a nonnegative number that cycles
// between zero and Int32.MaxValue once every 24.9 days.

using System;

class Sample
{
public static void Main()
{
int result = Environment.TickCount & Int32.MaxValue;
Console.WriteLine( "TickCount: {0} ", result);
}
}
/*
This example produces the following results:

TickCount: 101931139
*/

微软的机子开一开还是要重启一下的。。。

本文链接

JScript 中Date.getTime转.Net中的DateTime

2010-08-24T07:42:00Z

JS中的getTime与.Net中的DateTime.Ticks意义相近，所以相互转换时，需要用到这两个概念；但是getTime与 Ticks的意义有所区别，请看以下定义：

JS中getTime的定义：
getTime() 方法可返回距 1970 年 1 月 1 日之间的毫秒数。

C#中的Ticks
此属性的值表示自 0001 年 1 月 1 日午夜 12:00:00以来经过的以 100 纳秒为间隔的间隔数。

对几个词来说明一下，纳秒也叫毫微秒，相互之前的转换关系是：

1秒 = 10^3 毫秒
1毫秒 = 10^3 微秒
1微秒 = 10^3 毫微秒

查看getTime与Ticks的定义后，可以得知getTime以毫秒为单位，Ticks以100纳秒为单位，因此getTime与 Ticks相差了 1000 * 1000 / 100；getTime()从1970-1-1开始计算，而Ticks从0001-1-1开始计算，因此Ticks多了1970-1-1之前的时间；转换公式如下：

getTime() * 1000 * 1000 / 100 + DateTime.Parse("1970-1-1").Ticks

测试程序如下：

//JS时间转.net时间
long jsGetTime = 1247617999000;
Console.WriteLine(jsGetTime);
long jsBeginTick = DateTime.Parse("1970-1-1").Ticks;

long netTicks = jsGetTime  * 1000 * 10 + jsBeginTick;
DateTime dt = new DateTime(netTicks);
Console.WriteLine(dt.ToString("yyyy-MM-dd HH:mm:ss"));
DateTime dt2 = dt.ToLocalTime();
Console.WriteLine(dt2.ToString("yyyy-MM-dd HH:mm:ss"));

//.Net时间转JS getTime()；
long dt2Ticks = dt2.ToUniversalTime().Ticks;
long dt2JsTicks = (dt2Ticks - jsBeginTick) / (1000 * 10);
Console.WriteLine(dt2JsTicks);
Console.Read();

来自：

http://www.cnblogs.com/jordan2009/archive/2009/08/17/1547875.html

        private long GetJsTimes()
        {
            DateTime dt = DateTime.Now;
            long dtTicks = dt.ToUniversalTime().Ticks;
            long jsBeginTick = DateTime.Parse("1970-1-1").Ticks;
            long dtJsTicks = (dtTicks - jsBeginTick) / (1000 * 10);
            return dtJsTicks;
        }

        private DateTime ToDotnetTime(long jsTime)
        {
            long jsBeginTick = DateTime.Parse("1970-1-1").Ticks;

            long netTicks = jsTime * 1000 * 10 + jsBeginTick;
            DateTime dt = new DateTime(netTicks);
            DateTime dt2 = dt.ToLocalTime();

            return dt2;

}

本文链接

转：关系数据库中关系模式的规范过程

2010-07-21T14:59:00Z

转载自http://www.gotoread.com/mag/10343/contribution144381.html

一、引言

一个不好的关系模式存在插入异常、删除异常、更新异常和数据冗余。这些异常都是由不好的数据依赖造成的。而规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。规范化过程是围绕范式而进行的。一个关系型数据库中所有的关系，都应满足一定的要求，我们称为范式。根据满足不同程度的要求,把范式分为多种:满足最低要求的一级叫做一范式(1NF)，在一范式的基础上提出了二范式(2NF)，在二范式的基础上又提出了三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式的等级越高，应满足的约束条件也就越严格。规范的每一级别都依赖于它的前一级别，反之不成立。例如若一个关系模式满足2NF，则一定满足1NF。但若一个关系模式满足1NF，则不一定满足2NF。

是否规范化的程度越高越好?这要根据需要来决定，因为“分离”越深，产生的关系越多。关系过多，连接操作越频繁，而连接操作是最费时间的，特别对以查询为主的数据库应用来说，频繁的连接会影响查询速度。一般情况下，拆分到3NF是一个比较好的中间点。下面按照范式级别依次介绍1NF、2NF和3NF。

二、一范式（1NF）的规范化过程

一范式（1NF）：在数据库表中，每个属性都是不可再分的数据项，则该关系属于一范式。也就是说不允许表中含表的情况。第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。但是满足第一范式的关系模式并不一定是一个好的关系模式。

例如：关系学生课程表SC（Sno，Cno），其中Sno为学号，Cno为课程号。这样的关系模式在实际应用过程中会存在这样问题，一个学生可以同时选择多门课程，现将该关系中Sno作为码，Cno字段中存在了多个与之对应的值的情况，如下表所示：

Sno Cno

Cno1 Cno2 Cno3

20100001 C1 C2 C3

20100002 C1 C3 C6

这样的关系不满足第一范式的要求。因为Cno中有多个数据项。在实际应用中，设计的表，都应该满足第一范式。应改为如下表所示：

Sno Cno

20100001 C1

20100001 C2

20100001 C3

20100002 C1

20100002 C3

20100002 C6

三、二范式（2NF）的规范化过程

二范式（2NF）：如果某关系满足一范式，并且它的所有非主属性都完全函数依赖于码，则该关系满足二范式。也就是在一范式的基础上消除了非主属性对码的部分函数依赖。在判定是否为二范式时，一旦发现有一个非主属性部分函数依赖于码，则判定它不属于二范式。

例如：关系模式 SLC(Sno, Sdept, Sloc, Cno, Score)，其中Sno为学号、Sdept为系别、Sloc为学生住处，并且每个系的学生住在同一个地方。Cno为课程号、Score为学生成绩。其中每个学生可以选修多门课程，一门课程可以被多个学生选修。一个学生选定一门课程后就会产生一个成绩。根据语义，码为属性组合（Sno、Cno）。函数依赖图如下：

图中用虚线表示部分函数依赖。可以看到非主属性 Sdept、Sloc部分函数依赖于码。所以SLC∈2NF。

在应用中使用这个关系模式可能存在以下问题：

1. 插入异常。假设来了个新生还未选课，即Cno为空。如Sno＝95102，Sdept＝IS，Sloc＝N。因课程号是主属性，根据实体完整性，主属性不能为空或部分为空，所以该学生的信息无法插入SLC。另外，如果成立了一个新系还没有招生，即Sno、Cno都为空。根据实体完整性，该系的信息也无法插入。

2. 删除异常。假定某个学生本来只选修了3号课程这一门课。现在因身体不适，他连3号课程也不选修了。因课程号是主属性，此操作将导致该学生信息的整个元组都要删除。另外，如果一个系的学生都毕业走了，在删除学生信息的同时该系的信息也将被删除。

3. 修改复杂。

例如学生转系，在修改此学生元组的Sdept值的同时，还可能需要修改住处（Sloc）。如果这个学生选修了K门课，则必须无遗漏地修改K个元组中全部 Sdept、Sloc信息。在如系之间调整住处（Sloc），假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需无遗漏地修改1万次。

4. 数据冗余度大

假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需重复存放1万次。再如一个学生选修了10门课程，那么他的Sdept和Sloc 值就要重复存储了10次。

分析原因：非主属性Sdept、Sloc仅依赖于Sno这个字段，也就是Sdept、Sloc部分函数依赖于码（Sno，Cno）而不是完全函数依赖。

解决思路：消除了非主属性对码的部分函数依赖。

解决方法：用投影分解将关系模式 SLC进行分解。具体步骤如下：

把部分函数依赖于码的属性取出来；对SLC而言，取出属性Sdept、Sloc。

把剩下的属性构成一个独立的关系模式；对SLC而言，将剩下的属性Sno, Cno, Score构成一个独立的关系模式。即SC（Sno, Cno, Score）。

找出取出属性的决定因素并将它们放在一起构成一个独立的关系模式；对SLC而言，找出取出属性Sdept、Sloc的决定因素Sno并将它们放在一起构成一个独立的关系模式。即SL（Sno、Sdept、Sloc）。

综上所述，原关系模式SLC(Sno, Sdept, Sloc, Cno, Score)分解为两个关系模式：SC（Sno, Cno, Score）和SL（Sno、Sdept、Sloc）。

四、三范式（3NF）的规范化过程

三范式（3NF）：如果某关系模式满足第二范式，并且它的任何一个非主属性都不传递依赖于码，则满足第三范式。

例如：上述例子中的关系模式SC（Sno, Cno, Score）。根据语义，码为属性组合（Sno、Cno）。函数依赖图如下：

由图可知，码（Sno、Cno）函数确定非主属性Score，不存在非主属性对码的传递函数依赖，满足3NF。

再如：上述例子中的关系模式 SL（Sno、Sdept、Sloc）。根据语义，码为属性Sno。函数依赖图如下：

由图可知，码Sno函数确定非主属性Sdept，Sdept函数确定非主属性Sloc。Sloc传递函数依赖于Sno，即SL中存在非主属性对码的传递函数依赖。

在应用中使用这两个关系模式可能存在以下问题：

1. 插入异常。如果成立了一个新系还没有招生，即Sno为空。根据实体完整性，该系的信息也无法插入。但假设来了个新生还未选课，即Cno为空。如 Sno＝95102，Sdept＝IS，Sloc＝N。因学号非空，我们可以将该学生的信息插入SL中。

2. 删除异常。如果一个系的学生都毕业走了，在删除学生信息的同时该系的信息也将被删除。但假定某个学生本来只选修了一门课。现在因身体不适，他连一门课程也不选修了。在删除该学生选课情况时，学生的信息不会丢失。因为学生的学号非空，所以学生信息还在SL中。

3. 修改复杂。

例如系之间调整住处（Sloc），假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需无遗漏地修改1000次。但学生转系，不管一个学生选修了多少门课，都只需要在SL中修改1个元组的Sdept、Sloc信息。

4. 数据冗余度大

假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需重复存放1000次。但不管一个学生选修了多少门课，都只需要在SL中存放1个元组的Sdept、Sloc信息。

分解之后的两个关系模式SC和SL和原关系模式SLC相比：在一定程度上减轻原F关系模式SLC中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。但并不能完全消除关系模式中的各种异常情况和数据冗余。

分析原因：非主属性Sloc传递依赖于码Sno。

解决思路：消除了非主属性对码的传递函数依赖。

解决方法：用投影分解法将关系模式SL进行分解。具体步骤如下：

把传递函数依赖于码的属性取出来；对SL而言，取出属性Sloc。

把剩下的属性构成一个独立的关系模式；对SL而言，将剩下的属性Sno, Sdept构成一个独立的关系模式。即SD（Sno, Sdept）。

找出取出属性的决定因素并将它们放在一起构成一个独立的关系模式；对SL而言，找出取出属性Sloc的决定因素Sdept并将它们放在一起构成一个独立的关系模式。即DL（Sdept、Sloc）。

综上所述，关系模式SL (Sno, Sdept, Sloc)分解为两个关系模式：SD（Sno, Sdept）和DL（Sdept、Sloc）。

所以，原模式SLC(Sno, Sdept, Sloc, Cno, Score)按如下分解满足3NF：

SC（Sno, Cno, Score），SD（Sno, Sdept），DL（Sdept、Sloc）

在应用中使用这三个关系模式不会存在以下问题：

1. 插入不异常。如果成立了一个新系还没有招生，因为系Sdept非空，该系的信息可以插入DL中。假设来了个新生还未选课，因学号非空，我们可以将该学生的信息插入SD 中。

2. 删除不异常。如果一个系的学生都毕业走了，在删除学生信息的同时该系的信息不会被删除。因为系的系号非空，所以系信息还在DL中。又如某个学生本来只选修了一门课。现在因身体不适，他连一门课程也不选修了。在删除该学生选课情况时，学生的信息不会丢失。因为学生的学号非空，所以学生信息还在SD中。

3. 修改不复杂。

例如系之间调整住处（Sloc），不管一个系有多少个学生，住处（Sloc）只需在DL中修改1次。又如学生转系，不管一个学生选修了多少门课，都只需要在SD中修改1个元组的Sdept信息。

4. 数据冗余度不大

不管一个系有多少个学生，住处（Sloc）只需在DL中存放1次。但系（Sdept）还得多次存放。冗余只能尽可能减少，不能避免。因为如果没有冗余，数据间就没了联系。

五、结束语

本文分析了1NF、2NF、3NF。但是3NF只限制了非主属性对码的依赖关系,没有限制主属性对码的依赖关系。如果存在主属性对码的依赖关系，仍会产生插入异常、删除异常、数据冗余度大、修改复杂等问题。在此我们不作讨论,有兴趣的读者可参阅有关文献。

本文链接

个人宣传画

2010-04-19T14:38:00Z

2010-04-19T14:38:00Z2010-04-19T14:38:00Zyellowyuhttp://www.cnblogs.com/yellowyu/

本文链接

我的身体已不再属于我

2009-12-05T16:13:00Z

我的身体不再属于我我的眼精已快闭下,可我的意志还在告诉他,不行我的脖子已快倒下,可我的脑子还在告诉他,撑住我很想闭上眼睛去感受我的身体的呼唤轻轻地感受身体的负何与解脱但公司这边就有代码要调试,一百多条线程乱窜....但客户那边就有技术要支持,面对是行业里面的老大,问题很仔细,很琐碎....但家里这边就有年迈的双亲与不懂的弟弟但淘宝那边还有我的＂啡尝浪漫＂白咖啡专卖店.http://whitecaf...

每一条路都是坚辛的,从未有平坦的

2009-12-01T15:39:00Z

每一条路都是坚辛的,从未有平坦的如果当初未踏出那一步,我是否还留在上海,继续我的程序员之路呢如果不是因为金融危机,我是否还呆在所里,继续我的开发呢如果不是认识李总,我是否还呆在外地漂泊,海漂然后北漂呢怎么怎么这么多如果啊　....如果当时不是Honon面试我,让我感觉我找到一个Windows导师如果当时不是Honon指引我,让我寻找我自已学习的方向和道路如果当时不是Honon离开我,让我独自一人,...

程序员与白咖啡，一种心情

2009-11-26T06:15:00Z

喝咖啡要的是一种咖啡心情，无论是在轻雪飞扬的早春午后，还是阳光微斜的夏日黄昏，无论是秋雨绵绵的凉秋夜幕，还是凛风北起的严冬静夜，都能给人营造一种不同季节的咖啡心情。在这个深秋的午后，揣着咖啡，咖啡的醇香在身边萦绕。感觉这才是生活的味道，忙碌的生活的一刻放松品着咖啡的苦涩、混浊和醇香就象经历了岁月沧桑的成熟人生一样我不喜欢雀巢，很酸很涩，对身体不好我更喜欢白咖啡，温柔顺滑不伤胃闻着咖啡的醇香，有...

真实故事：我的女友

2009-11-13T11:58:00Z

傍晚时分，橘红色的太阳仿佛耗了全身的能量，疲惫地挂在天边，小区里灯火通明，工作了一天的人们陆续回到了温暖舒适的家，厨房里锅碗瓢盆的叮当声，让原本疲惫的煜打起精神来。 “老公，帮我把汤端出来，可以开饭了。” 好友希正在炒那最拿手的“红烧茄子”。那浓浓的香味是煜最喜欢的味道，一种家的味道。五年前从北方来到南方工作，他孤身一人，吃的、穿的都是很随便打发。...