Close connections to your IndexedDB databases

Recently, I was attempting to run the deleteDatabase method of the IDBFactory interface of the IndexedDB API.  I noticed that occasionally the method would just hang there like it was stuck.  I slowly began to realize that it would hang if a connection was currently open.  This led me to researching how to close connections.

When you open a connection using the open method of IDBFactory, you get an object of type IDBDatabase.  In my experience, the only thing you do with the IDBDatabase object is to create the transaction object from it.  After you create the transaction, you should then immediately close the IDBDatabase object which closes the connection you opened.  At first, I wondered if you had to wait until you were done with the transaction before closing the connection, but apparently the close method knows to wait until all transactions created from it are completed.  This is from the specification:

Wait for all transactions created using connection to complete. Once they are complete, connection is closed.

Your code should look something like what is shown below. In this case, request is the IDBOpenDBRequest object.

request.onsuccess = function() {
    var db = event.target.result;

    var tx = db.transaction(['TableName'], 'readwrite');

    db.close();
}

Left Outer Join using LINQ

Left outer joins are another example of something that's seems intuitive in SQL but appears foreign in LINQ.  Here we have two tables, TableOne and TableTwo both with a common TableOneId column.  TableOne always has a record and TableTwo has 0 to many records for each TableOne record.  The first query will return every record from both tables even if the TableOne record has no TableTwo record.  The second query will only return records from TableOne only if they have no corresponding TableTwo record.  By the way, this is VB.

'Without a where clause

Dim Query = 
    From t1 In TableOnes
    Group Join t2 In TableTwos On t1.TableOneId Equals t2.TableOneId Into gj = Group
    From grouping In gj.DefaultIfEmpty
    Select t1, grouping


'With a where clause

Dim Query = 
    From t1 In TableOnes
    Group Join t2 In TableTwos On t1.RecordId Equals t2.RecordId Into gj = Group
    From grouping In gj.DefaultIfEmpty
    Where grouping Is Nothing
    Select t1, grouping
 

Security Auditing in WCF

It is possible to log all security successes and/or failures to the event log by just modifying your configuration file.  This can be a quick and easy way to see if any funny business is going on with your web service.  However, a better solution is to log these types of events to a database that is easier to check and query on if you're doing this on a regular basis.

I'm a fan of the Service Configuration Editor tool (In Visual Studio, right click the web.config and select Edit WCF Configuration) rather than changing the XML directly, but it's helpful to see both.

First add a Service Behavior Configuration.  It doesn't necessarily have to be named.  Then add the serviceSecurityAudit behavior to the configuration:

Now, expand the behavior configuration, and select the newly added serviceSecurityAudit:

I recommend choosing the "Application" log as the location.  Here, I have chosen to log both successes and failures at the message level.  Once this is set up, simply go to the Event Viewer and you'll see information entries for each authentication or rejection.  To turn it off, just set it to None and leave it in the web.config in case you want to turn it on again.

Here is the settings as they exist in the XML:

<behaviors>
  <servicebehaviors>
    <behavior name="">

...

      <servicesecurityaudit auditloglocation="Application" 
          messageauthenticationauditlevel="SuccessOrFailure" 
          serviceauthorizationauditlevel="None">
      </servicesecurityaudit>
    </behavior>
  </servicebehaviors>
</behaviors>

Query XML files with LINQ

If you regularly work with XML, knowing a technique to directly query it can be a real asset.  I have found LINQ to XML together with LINQPad to be really helpful.  The best thing to do is to simply show an example.  Here we have a trivial XML file that we load in and display:

Then, let's say we want to list all plants from the file:

The tricky part is that if there are namespaces in your xml (and there usually is), then you need to include the namepace in braces.

Manually perform GET and POST HTTP actions

In an earlier post, I talked about HTTP and how to use the TELNET client to manually perform HTTP requests independent of a browser.  TELNET works great when playing around with requests on your local PC, but gets finicky when trying to connect to remote servers.  Plus, it's just plain tedious to work with.

I found that a better alternative is to write a little program to make these requests and then output the response to a text file.  It's actually pretty simple to do this in .NET by using the WebRequest class.  Here is a link to where you can find everything you need to know about WebRequest.

Simple .NET Web.Config Transform Files

Let's say you have a web application, and you're ready to publish the changes either to test or production.  After you get the files published to the web server, you have to go into the web.config file and change the settings so that it points to the proper environment (database connection strings, web service URLs, etc.).  Most times you remember to do this, but sometimes you don't.  Or maybe you have somebody else do it, and they forget.  Or sometimes the web.config gets deleted from the web server, and you have to guess what all the settings were.  This is where a transformation file can really help.

Visual Studio automatically generates a transform file for both the release and debug configurations.  You can see these by clicking "Show All Files" and expanding the web.config.  The transform file is just a set of rules telling the publish profile how to change the web.config for that configuration.  A simple example is below:

  
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.serviceModel>
    <client>
      <endpoint name="TheWebServiceName" address="http://www.thisisfake.com/FictionalService.svc" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" ></endpoint>
    </client>
  </system.serviceModel>
</configuration>

Our web application calls a web service that is at a different URL in production than in our development environment.  Above is a simple example of a transform file that changes the address attribute of the endpoint element when the name matches "TheWebServiceName".