[SSIS] How to remotely run a DTSX package from bat file?

Short answer (or at least the conclusion I came to after a fair amount of research  - and plenty of hair pulling): you can't .

Long Answer: I started from this cmd, which works like charm locally:

DTEXEC /DTS "\File System\MY_PACKAGE_NAME" /SERVER MY_SERVER_NAME /MAXCONCURRENT " -1 " /CHECKPOINTING OFF  /REPORTING V

If you try to use the same cmd remotely it will miserably fail with some nasty timeout.

After a bit of googling it looks like it is impossible to run DTEXEC cmd remotely (it needs to be run locally - remote execution apparently is not supported).

To overcome this limitation the following method seems to be broadly implemented:

• set up a SQL job to run the DTSX package
  
• set up a Stored Procedure to run the job
  
• use isql command line in a BAT file (remotely executed) to run the stored procedure on the relevant SQL instance (with SQL credentials and not machine credentials)

Might work - but kinda sucks.

[.NET] Why are Exceptions not Checked in C#?

Going from Java to C#, I've been stunned by the absence of  the "throws" clause in the declaration of a method, in which you want to throw a particular exception.
Actually it hasn't caused me so much pain, but the knowledge at compile time of the possibility that an exception could be thrown sounded very useful to me.
Asking to the StackOverflow community, I found out Java is one of the few programming languages where exceptions are "caught" at compile time.
The philosophy behind C# is that what is useful about exceptions is not handling them, but mostly cleaning resources, implementing the IDisposable pattern (The trouble with Checked expcetions).
If you know that a particular method can throw an exception, you also know what it does and how to handle it, otherwise you will handle a generic exception, without need to specify it at compile time; moreover handling exceptions is something that comes near the caller of a method reather than the method itself, so there is no need to specify a chain of "throws" declarations, and that is so useful in versioning, because adding a new exception (or removing an old one) doesn't require a refactoring of your lib.
It is worth noting that C# supports the <exception> tag in the documentation section, with which the compiler informs you that an exception (whose type is anyway checked for existence) can be thrown, without any further constraints.
If you have other issues or different opinions I'd like to hear them.

Good butchering!

ICONIX Process Rocks

Today we talk about my favorite software development process, so-called ICONIX.

This should probably give an answer to the few dinosaurs who like going around saying that AGILE is an excuse for not having a well-defined process (they probably think the V-Model still rocks - good lads).

ICONIX adopts a subset of core AGILE techniques and it is a behavioral requirements (Use Cases) driven process. The ICONIX process aims to be as low-celebration as possible carrying as little documentation as possible through iterations - in order to allow you to easily keep it up-to-date (this is a big difference from other AGILE processes, as XP, which aim at carrying no documentation at all).
For fans of TDD (Test Driven Development), it has been proved that ICONIX can be easily paired with the latter: http://www.springerlink.com/content/k15l318vq1013057/

Here's a practical overview of the process:

1. Quick Draft of Functional Requirements (in theory throw-away)
   
2. Quick Definition of a Domain Model (identify entities and classes)
   
3. Model Use Cases on the base of previous steps (This is what drives development)
   
4. Draw a throw-away robustness diagram for each use case (to understand relations between your classes)
   
5. Draw a Sequence Diagram for each use case (here you'll understand which methods you really need)
   
6. Model your test-cases on the use cases
   
7. Implement
   
8. Test

At each step you review your work as a whole updating your domain model (it's impossible to get it right first time) and adding comments on your use cases. By the end of step (5) you end up with ready-to-implement classes and logic with just little documentation to maintain if you re-factor or change anything. The following is indeed the only documentation you need to carry through iterations:

• Use case diagram
  
• Sequence Diagram for each use case
  
• Test case diagram (or test plan)

If you need to add features, you add new use cases and follow the whole process.

 
In my experience the ICONIX process works regardless of the size of the project. In a medium-large project you just split the implementation of features in short iterations in an AGILE fashion. It is worth underlining that the big difference between most extreme AGILE processes and ICONIX is that you do keep documentation up-to-date, you don't just throw it away after each iteration. This is possible because the process aims (again) at keeping very light-weight documentation.

Resources:

Iconix process website

Iconix Software Engineering website

Books References:

AGILE Development with ICONIX Process

[JAVA] Calendar Months Start from Zero

I don't have time to make a big deal out of this but please tell me which month is the 12th one in the year. I was so stupid to think it was December. Thanks to the JAVAAPI guys I got enlightened. The 12th month is Janaury cause the count starts from 0, it goes to 11 and then starts over again. Grand job to the java.util.Calendar guy!

[.NET] How to Programmatically Create and Access Custom ConfigurationSections

.NET app.config and web.config are powerful instruments to store simple key value pairs and connections strings.When you need to store config data in some specific format and key value pairs are not enough you can use Custom Configuration Sections as they are not complex to use (unless you need a fairly complex section):

1) Define your custom section:

public class CustomSection : ConfigurationSection
{
[ConfigurationProperty("LastName", IsRequired = true,DefaultValue = "TEST")]
public String LastName
{
get { return (String)base["LastName"]; }
set { base["LastName"] = value; }
}

[ConfigurationProperty("FirstName", IsRequired = true, DefaultValue = "TEST")]
public String FirstName
{
get { return (String)base["FirstName"]; }
set { base["FirstName"] = value; }
}

public CustomSection()
{

}
}

2) Programmatically create your section (if it doesn't already exist):

// Create a custom section.
static void CreateSection()
{
try
{

CustomSection customSection;
// Get the current configuration file.
System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");

// Create the section entry
// and the
// related target section
if (config.Sections["CustomSection"] == null)
{
 customSection = new CustomSection();
 config.Sections.Add("CustomSection", customSection);
 customSection.SectionInformation.ForceSave = true;
 config.Save(ConfigurationSaveMode.Full);
}
}
catch (ConfigurationErrorsException err)
{
//manage exception - give feedback or whatever
}

}

Following CustomSection definition and actual CustomSection will be created for you:

 <configuration>
 <configsections>
 <section name="CustomSection" type="ConfigurationTest.CustomSection,    ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowlocation="true" allowdefinition="Everywhere" allowexedefinition="MachineToApplication" overridemodedefault="Allow" restartonexternalchanges="true" requirepermission="true">
 </section>
 </configsections>
 <customsection lastname="TEST" firstname="TEST">
 </customsection>
 </configuration>

3) Now Retrieve your section properties:

CustomSection section=(CustomSection)ConfigurationManager.GetSection("CustomSection");
string lastName = section.LastName;
string firstName = section.FirstName;

This is all good stuff - nice and easy as you can see.

P.S. This post orginally appeared on this  StackOverflow link, but since I wrote it I thought it would do no harm to recycle my own rubbish here.