Site Logo

Posted by Darrick on November 18th 2005 to Development
I’ve installed and used MSDE enough times to realize that these 2 steps / options are quite important to me, and often forgotten during the command line install.

1. Allow mixed mode authentication
By default, the MSDE setup allows only Windows authentication, even though a strong password is supplied with the command line install.

Modifying this after install requires a change to a registry key. Depending on whether or not you specified an instance name, it would require a change of value from 1 to 2 in:
HKLM\Software\Microsoft\MSSqlserver\MSSqlServer\LoginMode (if default instance)
or
HKLM\Software\Microsoft\Microsoft SQL Server\Instance Name \MSSQLServer\LoginMode (if named instance)

To avoid this, I use the SECURITYMODE=SQL parameter in the command line.

2. Allow TCP/IP connection
The default install actually prevents any TCP/IP connection to MSDE, meaning you cannot remotely connect to it from another computer in Enterprise Manager, nor connect to it from applications outside the local computer. I understand that MSDE is just for development purposed, but sometimes I just need to test application connectivity from a remote machine.

To change this after installation requires you to run a file called SVRNETCN.EXE within
C:\Program Files\Microsoft SQL Server\80\Tools\Binn (if default install, otherwise similar directory based on your install), where you add the TCP/IP protocol

To set this up at install, I use the DISABLENETWORPROTOCOLS=0 parameter in the command line.

Ads by AdGenta.com

So my usual MSDE command line installation goes like this:
setup sapwd=”” securitymode=”sql” disablenetworkprotocols=”0″
Saves me the time of having to do those extra steps afterwards.

Technorati Tags : ,
Powered By Qumana

Average Rating: 4.9 out of 5 based on 294 user reviews.

[ | | | | ]

No Comments

Posted by Darrick on September 02nd 2005 to Development
For the last week or so, I’ve been studying interestedly some agile / lightweight methodologies/processes of software development, with the main one being Extreme Programming (XP in short, not to be confused with Windows XP). As a result of studying, I’ve come upon the concept of Test Driven Development (TDD). Now while I know there are various pros and cons to using XP (and I’ll hold judgement on whether it’s a good thing or bad thing), I can’t seem to find any disadvantages of adopting TDD into how to develop applications.

The basic process of TDD goes like this:
- Write a test (that’s right, even before the code)
- Watch it fail
- Write code to make test pass
- Refactor if necessary
- Repeat

There are various arguments running around against TDD allowing design to grow from these tests, as opposed to doing design upfront and before any code is written. But I think that in either case, a test driven process can be used for the improvement of code. By writing tests upfront, whether with a Bid Design Up Front, minimal design or no design at all, it saves quite some time from bug hunting and fixing once the software is more complex and developed.

For me, doing a couple of examples with TDD has been exhilarating and quite enjoyable. I never ever thought I’d enjoy writing tests for applications, but to see that tests actually improve quality and even drive how an application gets built is quite amazing. I’d really recommend giving TDD a try in your next development project.

Powered By Qumana

Average Rating: 4.6 out of 5 based on 162 user reviews.

[ | | | | ]

No Comments