SQL Server Compact Edition – Still an option for lightweight persistence?

Recently, I was looking for a lightweight database for a small, independent application. One requirement was an easy deployment without installation of additional software on the server. The first thing that came to my mind was SQL Server Compact Edition. Technically it fulfilled all requirements perfectly but than I stumbled across this Connect Article.

“SQL Server compact edition is in deprecation mode with no new releases planned near future”

Sadly this disqualifies SQL Server Compact Edition for the use in a productive application and the recommended SQL Server Express or LocalDB do not really replace it.

Now the big question is, what to use instead of SQL Server Compact Edition for the use case of a lightweight, easy to deploy database on a Windows Server?

SSIS – Unexpected Termination

I did observe a confusing behaviour after patching a SQL Server 2012 to Service Pack 2. Some of the SSIS jobs running on that server started to fail with the message Unexpected Termination while most of the other jobs just worked as before.

Unexpected Termination can have multiple causes and if you search for that error in the internet you can find a bunch of different reasons and solutions. But non of them worked and to make the situation worse the jobs running on other servers without the Service Pack still worked. So I started looking into the known issues of the Service Pack and luckily I found this link: http://support.microsoft.com/kb/2991528 

The error did not exactly match the entry I could find in the Event Viewer but all failing jobs used DT_TEXT or DT_NTEXT. I decided to risk installing the Cumulative Update (http://support.microsoft.com/kb/2983175) containing the fix. After this, the jobs started to work just fine. So in the end the solution was extremely simple.

This is just one possible solution for the Unexpected Termination error but if you experience this error after installing Service Pack 2 you should definitely check if this is also your problem.

JavaScript – Documenting optional parameter

JavaScript is an awesome language but due to its nature parameter documentation is pretty important especially when it come to optional parameters. If you want to create a method like this:

module.exports.create = function (callback) {
    // Do something
    if (callback) {
        callback();
    }
}

Obviously, callback is an optional parameter but if we use this method in an IDE like JetBrains WebStorm it will always show us a wrong signature warning and other developers might think this parameter is mandatory.  We can overcome that situation by adding the correct comment on this method.

/**
 * The method does something. 
 * 
 * @param {requestCallback=} callback
 */
module.exports.create = function (callback) {
    // Do something
    if (callback) {
        callback();
    }
}

Now the IDE and other developers looking at our method know that the parameter is optional and can use it like that. This syntax can be used to provide a lot of information on the different request parameter. This link contains a very detailed description.

Object # has no method ‘flash’ undefined TypeError: Object # has no method ‘flash’ at allFailed

Recently I was playing around with Passport.js in an Express application. I created a login route that logged like that:

passport.authenticate('local', {
    successRedirect: '/app',
    failureRedirect: '/login',
    failureFlash: false
});

Everything worked fine and I could login to my application but I also wanted to show a message when the login fails. So I changed my route to:

passport.authenticate('local', {
    successRedirect: '/app',
    failureRedirect: '/login',
    failureFlash: true
});

Instead of redirect back to the login page I got this exception:

Object #<IncomingMessage> has no method 'flash' undefined TypeError: Object #<IncomingMessage> has no method 'flash' at allFailed

The solution for this is simple. I forgot to include the connect-flash module that provides the flash method. So I changed my startup code:

var flash = require('connect-flash');
app.use(cookieParser());
app.use(flash());

Even so the solution is quite simple and somehow obvious. It doesn’t seem right that changing a property to true introduces the need for a new middleware.