We've reached capacity and have officially sold out! Looks like this is going to be awesome event!
The fine folks over at 3-Leaf have a nifty little posting up
about using SQL Server Express 2005 with downlevel
like VB6 clients that's well done. There's just a couple of nits to pick.
- In order to use "AttachDBFileName" option, you have to be using the SQL
Native Client. Other SQL Server Providers won't support this option.
- As Bob Beauchemin has talked about in his, there's some behavior
differences with that provider to keep in mind:
- Classic ADO isn't going to understand some of the new data types and
features supported by SQL Server 2005 Express like the XML type and CLR UDTs.
But I must full agree with and praise them drawing the right conclusion:
I never thought that all these .NET innovations... would provide so much
benefit for non .NET (VB6, ASP, etc.) developers, but it is a huge win for the
down-level camp.
Suppose you've got the following on a computer you are working with...:
- Any edition of SQL Server 2005 installed with mixed authentication mode support enabled
- A local and/or group policy that applies that computer controlling login attributes like when an account expires, minimum password strength, length and so.
- You've created one or more standard logins when such policies were being enforced by that computer.
There's a subtle and sometimes overlooked change with SQL Server 2005 that applies to both Standard and Windows Integrated logins. It's pretty easy to understand why such policies would affect a Windows Integrated login, but its not so obvious that the same policies would be applied to a standard login. However, surprise, they are!
That's a feature, actually, since it improves the security of the system. But it can also be a real problem since there's no notification provide that a login is about to or has gone stale. While its a best practice not to circumvent this behavior, it is possible. The easy way to tell SQL Server to ignore the applicable policies when you generate the login. There's two options in the CREATE LOGIN statement that help you do this:
- CHECK_EXPIRATION, which does what the name implies
- CHECK_POLICY, which verifies that the given password does, in fact, comply with the applicable length and strength policies.
Here's an example of creating a login that overrides the password expiration policy, but does enforce any applicable length and strength policies.
CREATE LOGIN MyAppLogin WITH PASSWORD='Something4U2Try2Guess', DEFAULT_DATABASE = Orphange, CHECK_EXPIRATION = OFF, CHECK_POLICY = ON
I just posted the questions and answers from my chalk talk session on SQL Server 2005 Express (hereinafter referred to as SSX) at Code Camp II. Note that I’ve rephrased some of the questions to better suit this format. Many thanks to Aaron Weiker of http://aaronweiker.com/ for capturing these notes during the session
Continues here.