Archive for October 2010
23
Adding Domain Users to a Server 2008 R2 Domain
No comments · Posted by Larry.Smithmier in Active Directory, Command Line, Domain Controller, dsadd, Examples, Script, Server 2008 R2
I have a long list of users to add to an existing domain, and using the Active Directory Users and Computers GUI:
is an easy way to add a couple of users:
but with over 40 to add, it would take too long. How can I speed this up? dsadd to the rescue! The command line you would use to add a new user is:
dsadd user "CN=First Last,CN=User,DC=corp,DC=productiveedge,DC=com" -samid first.last -pwd qwerty123! -mustchpwd yes
so you can create a script to add users to a domain relatively easily. Note the:
-mustchpwd yes
at the end of the line. That is added to require the user to change their password on the first login.
Active Directory · Add User · Command Line · Domain Controller · dsadd · Example · Script · Server 2008 R2
16
How to Troubleshoot SQL Server Connection Issues
No comments · Posted by Larry.Smithmier in SQL
The easiest way to test connection issues with Universal Data Link (.udl) files. No code required. Simply create an empty text file on a Windows machine with the extension .udl and double click it.

A wizard pops up and you can test your configuration pretty quickly. If you did a default install of anything other than SQL Express, your instance name (the part to the right of the ‘\’ below) will default to MSSQLSERVER and shouldn’t be shown in the server name. If you installed SQLExpress, your instance name will be SQLEXPRESS.

And, as a bonus, once you get it working you can open it in a text editor and extract your connection string. If it doesn’t work on your local box, try it on the server itself. If that works, skip on down to the end of this for the culprit.
You can also attempt to telnet directly to port 1433 (the default TCP/IP port for SQL Server) to test connectivity. You won’t see anything once you get there, but if the connection succeeds, you are in business.
If you are not running SQL Server locally, you could also get into trouble if remote connections are not allowed. To check/change this, Open up Management Studio and right click on the instance you are connected to:

open the properties window:

and go to the connections tab and insure remote connections are allowed:

If none of that works, the problem you are probably having is related to the setup of SQL Server itself. Open up the SQL Server Configuration Manager:

then go to the SQL Server Network Configuration:

then double click on the Protocols for MSSQLSERVER:

and make sure that TCP/IP is enabled:

If TCP/IP is enabled, you may be running into firewall issues (it requires port 1433 by default, but it can be configured to a different port). To see which port your SQL instance is running on, double click on the TCP/IP icon to open the properties page and on the IP Address tab you will find the TCP port you are running on:
connect · SQL Server · troubleshooting · UDL · Universal Data Link
4
Looking up Stored Procedures Containing ‘%x%’
No comments · Posted by Larry.Smithmier in Examples, Snippit, SQL
This isn’t really big news, but I have had to look it up twice in the last quarter. To find which stored procedures contain a specific text string, use:
SELECT Name, OBJECT_DEFINITION(OBJECT_ID) FROM sys.procedures sp WHERE OBJECT_DEFINITION(OBJECT_ID) LIKE '%Language%'
Example · SELECT · SQL Server · Stored Procedures · sys.procedures
2
Mystery Constants: Maintainability
No comments · Posted by Larry.Smithmier in C#, Examples, IntelliSense, Legacy, Maintainability, Visual Studio
Working with legacy code is always one of my favorite things to do. I believe it helps me write more maintainable code, and the little mysteries are always quite engaging. The most recent example that I feel compelled to share is related to the setting of a database value based on the selection made in a radio button group. In this particular instance, a set of custom localization routines help cloud the issue by abstracting the text from the code, but the central fault is more universal. There was an undocumented naming convention that was initially followed within the database, but the constraints on columns were not always put in place to enforce the convention and the code itself was not designed to assist in any way.
On to specifics (altered to insure confidentiality).
- Initially, in the UI there are three radio buttons that correspond to an integer column in the database (color). The value is set on a public property of an object that corresponds to the table (widgets) in the database. There is a corresponding dimension table (widgetColorCode) in the database, but there is a missing foreign key constraint and the naming convention doesn’t make it easy to track down the dimension domain.
- Time passes.
- A new UI is built for a new company that only manufactures red Widgets. The combo boxes are removed, and the value is set upon submission to the constant 1.
- A derivative of the new UI is commissioned that is for a company only supplying blue Widgets. There is nothing in the code to help the programmer find what value this property should have.
So the code for the Widget class looks something like this:
public class Widget
{
public int Color { get; set; }
}
I am a firm believer in having enumerations corresponding to all dimensions in a project. There is a performance hit for converting an enumeration to an integer, but it is far outweighed by the increased maintainability of the code. By explicitly setting the values for the enumeration and adding an XML comment relating it to the dimension table, you can greatly increase the maintainability of the code. When starting from scratch on a project, I will typically have something along the lines of:
////// corresponds to the Widget fact table /// public class Widget { public WidgetColor Color { get; set; } } ////// corresponds to the WidgetColorCode dimension table /// public enum WidgetColor { Red = 1, White = 2, Blue = 3 }
But, that is a personal preference, and refactoring the entire code base at this point can’t be justified. What can be done quickly to lessen the impact of this when further maintenance is required? Visual Studio comes to the rescue! By simply adding an XML comment to the property, we can define the dimension so that hovering over the property will display the dimension information (Please excuse the missing pointer in the image, trust me, I am hovering over the Color property.):
////// corresponds to the Widget fact table /// public class Widget { ////// corresponds to the WidgetColorCode dimension table /// 1: Red, 2: White, 3: Blue /// public int Color { get; set; } }
C# · DotNet · enumerations · Example · IntellliSense · Legacy code · Maintainability · Visual Studio
