Comments for geek#

Comment on EF4: Bug in StoreGeneratedPattern SSDL by Scott Anderson

Scott Anderson — Tue, 20 Jul 2010 14:42:05 +0000

Hey Wim,

Thanks for the feedback. I guess for me, it’s a lot less work to edit a few lines in my EDMX because I didn’t have a ton of these fields laying around. To each his own.

Cheers!

Comment on EF4: Bug in StoreGeneratedPattern SSDL by Wim

Wim — Tue, 20 Jul 2010 03:22:27 +0000

I had the same problem. I have solved it by using a SP that is mapped to a table that does not have any computed fields. But when then EF sends the data to my SP I save it to the real table leaving the fake table empty.

In the real table I can then use ID’s datetimes etc.

This is much less work then editing the EDMX the sole problem is that I get a lot of fake tables in my database.

Regards

Wim

Comment on Visual Studio 2010 Context Menus…WTF? by Jon

Jon — Thu, 01 Jul 2010 13:11:10 +0000

Yeah this is totally driving me nuts to the point where I even googled and found your post!

Comment on Windows + Ruby Native Gems (1.9.1) by Fat Guy in a little coat, Ruby on Windows | Victus Spiritus

Fat Guy in a little coat, Ruby on Windows | Victus Spiritus — Tue, 29 Jun 2010 12:25:14 +0000

[...] to work flawlessly. Luckily Scott Anderson posted a useful trick for debugging native extensions at Geeksharp.com (thanks Scott). You gotta love the ability of hackers to figure something out, and share it with [...]

Comment on EF4: Bug in StoreGeneratedPattern SSDL by Jason Sobell

Jason Sobell — Tue, 22 Jun 2010 01:57:32 +0000

This is not really a satisfactory workaround, and I really hope the Microsoft guys think about this when implementing their solution;
The database attribute we are using here is “Default Value or Binding”, not “Computed Column”.
In other words, if you supply a value for this field it should be accepted inplace of the default, but adding StoreGeneratedPattern=”Identity” or StoreGeneratedPattern=”Computed” causes the field value to be completely omitted from the SQL insert so there is no way to override any default value.

Comment on EF4: Bug in StoreGeneratedPattern SSDL by Sifty Tom

Sifty Tom — Mon, 21 Jun 2010 09:43:33 +0000

Gnngh! This bug drove me nuts.. why have the option enabled in the designer AND the documentation live with no mention of this bug. THANK YOU!

Comment on EF4: Bug in StoreGeneratedPattern SSDL by Bryant

Bryant — Fri, 18 Jun 2010 16:01:42 +0000

I found this post just in time- my frustration was about to boil over into violence against my keyboard. Thanks!

Comment on EF4: Bug in StoreGeneratedPattern SSDL by Noam Ben-Ami

Noam Ben-Ami — Fri, 28 May 2010 19:51:37 +0000

Hello Scott! Yes, we are very much aware of this bug. It is one of our top four issues to fix in the designer’s next release. Not sure why the connect bug was set as fixed.

Comment on MySQL Password Hashing in .NET by Scott Anderson

Scott Anderson — Thu, 27 May 2010 13:01:18 +0000

Thanks for the heads up, Adam. I guess things probably changed a little bit in 5.1.

Comment on MySQL Password Hashing in .NET by Adam Lundrigan

Adam Lundrigan — Thu, 27 May 2010 12:04:43 +0000

Excellent article. I have used your GenerateMySQLHash function in one of my C# apps, and I noticed that it doesn’t generate the correct MySQL >4.1 hash. For example, I chose a simple test password and ran it through both your function and the MySQL 5.1 command line:

Your Function: *46D8C7BAEFF461D8F821A61F07CD06FFB2D0
MySQL 5.1: *46D8C7BAEFF40601D8F821A601F07CD006FFB2D0

I found that changing b.ToString(“X”) to b.ToString(“X2″) at line 9 of your code fixed the problem.