Guy Starbuck

I've built a wrapper application that abstracts Salesforce.com integration with our CRM, and came across a bit of an obscure bug yesterday.

The issue came up when assigning a .NET DateTime value to a DateTime field in the generated SFDC proxy:

SFDCObject__c _sfdcObject = new SFDCObject__c();
_sfdcObject.Created_Date__c = DateTime.Now;
_sfdcObject.Created_Date__cSpecified = true;

When assigning the .NET DateTime value to the _sfdcObject.Created_Date__c member, an error is thrown:

ex = {"'2008-02-20' is not a valid value for the type xsd:dateTime"}

A bit of digging brought up this thread on the Salesforce.com developer discussion boards.  It turns out that the culprit is actually a bug in .NET 2.0 (quote is from the discussion thread):

If a schema contains both “xsd:date” with nillable=true and “xsd:dateTime” with nillable=true, we will import either both as “date” or both as “dateTime”. In your case, both probably get imported as “date”, hence the time component cases a failure. This is a known bug and there is a hotfix available (KB 925272), available by calling PSS.

The hotfix would need to be installed on all servers and dev machines, which seems like a non-optimal solution, so I went with the workaround of hand-modifying the WSDL to replace all instances of "xsd:date" with "xsd:dateTime".  This worked for me because my application only needs to work with SFDC objects that are defined as "xsd:dateTime".  If you have an app that needs to work with both xsd:date and xsd:dateTime typed fields, you will most likely need to install the hotfix from Microsoft, or move your solution to .NET 3.0 or 3.5.

One of the primary reasons I am writing this blog is to give back to the community -- technical blogs and message board archives have saved my bacon many times, so my plan is, whenever I spend an hour or two figuring something out and I wasn't able to find any concise resources about it, I'll write a post on it so that the next person may stumble across it and save some time.

Yesterday I was working on calling cmd.exe from within .NET, and had to piece together a few things from various places.  Here is the code I ended up with.  I've added comments to explain the reason for each line of code -- hopefully someone will find this helpful.

using System;
using System.Diagnostics;

namespace Utilities
{
    public class Command
    {
        public static string ExecuteCmd(string arguments)
        {
            // Create the Process Info object with the overloaded constructor
            // This takes in two parameters, the program to start and the
            // command line arguments.
            // The arguments parm is prefixed with "@" to eliminate the need
            // to escape special characters (i.e. backslashes) in the
            // arguments string and has "/C" prior to the command to tell
            // the process to execute the command quickly without feedback.
            ProcessStartInfo _info =
                new ProcessStartInfo("cmd", @"/C " + arguments);

            // The following commands are needed to redirect the
            // standard output.  This means that it will be redirected
            // to the Process.StandardOutput StreamReader.
            _info.RedirectStandardOutput = true;

            // Set UseShellExecute to false.  This tells the process to run
            // as a child of the invoking program, instead of on its own.
            // This allows us to intercept and redirect the standard output.
            _info.UseShellExecute = false;

            // Set CreateNoWindow to true, to supress the creation of
            // a new window
            _info.CreateNoWindow = true;

            // Create a process, assign its ProcessStartInfo and start it
            Process _p = new Process();
            _p.StartInfo = _info;
            _p.Start();

            // Capture the results in a string
            string _processResults = _p.StandardOutput.ReadToEnd();

            // Close the process to release system resources
            _p.Close();

            // Return the output stream to the caller
            return _processResults;
        }
    }
}

Back in the late 90s, I worked on a number of projects where we had to generate fixed width flat files to send to external systems -- we would use the SQL Server DTS wizard to generate them, and everything worked fine.

I recently needed to generate fixed width flat files from SQL Server 2005, so I ran SSIS and everything looks pretty much the same as DTS -- except when choosing "Fixed Width" as the export option, the entire flat file was generated with no linefeeds/carriage returns in it.

It turns out there is another option, "Ragged Right", which is exactly the same as "Fixed Width", except that it gives you the option to insert a linefeed character (or CRLF, etc.) at the end of each line of data.

Here's a quick walkthrough for generating fixed width flat files with line breaks from SSIS.  For this example, I'm assuming that we'll be selecting data "as-is" from a staging table that is already set up with the correct column widths and contains data exactly as it should be in the fixed width file.

1) In SQL Server Management Studio, right click on the database containing the table or data you want to export, and select "Tasks/Export Data..."

2) For the data source, you can leave the default settings.

3) For the target, select "Flat File Destination" as the Destination, pick a file name, and under "Format", select "Ragged right"

4) Click through the next dialog, which gives you the option to specify a query or just select straight from a table.  We're going to select from a table here.  On the "Configure Flat File Destination" screen, pick the table you want to export, and choose the row delimiter.  The default is "CRLF", which is generally good for windows, but if you are sending the file to be processed on another OS or for a specific app, you may need to choose a different linefeed character or sequence.

That's it!  Execute the package or save it off, and you should have a fixed width flat file with linefeeds.