The short version

The Market application on my HTC Aria Android phone would not download any new applications or application updates. I fixed it by performing a hard reset on the phone (resetting it to factory defaults) and then configured the phone to use a Google account that had Google Talk enabled. At that point, I could once again download applications.

The long version

This morning, I needed to download an application on my HTC Aria. The Market quickly stated that it was starting the download. Thirty minutes later, it continued to say "Starting Download". While poking around in the Market, I wound up on a screen that showed 3 other downloads (e.g., Google Maps, Kindle, and Nook) that were still "starting". Basically, the downloads were stuck and had been stuck for days. Argh!

Tonight I spent quite some time researching this problem. A Google search led me to articles stating this was related to Google Talk. There were also some message boards talking about the same issue. Some people were able to successfully download from the Android Market after signing into Google Talk. For many others, this had no effect. Some people mentioned doing a hard reset.

When I first used my phone, I connected it to my primary Google account. It's worth noting that this particular account is a free Google Apps account which does *not* have access to Google Talk. In the hopes that signing into Google Talk through my phone would solve the problem, I enabled Google Talk for my secondary Google account and added that account to the phone. No effect.

I tried a couple other things such as uninstalling updates for the Market application and clearing its data. Again, no effect.

The solution: I performed a hard reset on the phone. As I walked through the set up process, I skipped adding a Google account. Then I opened the Market application. It required me to sign into a Google account. I signed in using my primary account credentials. This time, the phone displayed a message saying that the account could not be used because it does not have access to Google Talk.

Interesting.

I re-authenticated with Google using the secondary account with access to Google Talk. I then went to Market and successfully downloaded the application.

Tonya Hall is a local radio host (or is it hostess?) whom I've had the benefit of getting to know over the past couple of years. She's created a show focused upon the people who are doing great things in the social media arena. Recently (i.e., this week), her show has moved from a Saturday-only schedule to a daily schedule. To give her website an up-to-date look and feel, Holly Aldridge (www.hollyaldridge.com) quickly put together a great look and feel. Then I turned it into a strictly HTML/CSS site. You can see it at www.tonyahall.net.

Back in August of 2010, I was hired by HDI to create an online professional community for their members and non-members. The site lives at http://www.hdiconnect.com and went live in November 2010. Since then, we've issued a couple of updates. Goals for the site included building a community where people in the helpdesk niche could interact around such subjects as Support Operations, Service Management, and Desktop Support, where non-members could learn about the benefits of becoming an HDI-certified professional, and where the HDI marketing and content teams could add and modify the website content without being bottlenecked by the business solutions team.

From an implementation perspective, this was a challenging project because I needed to integrate 3 software products with which I had no familiarity. I love challenges!

The core of the solution is Sitecore CMS. It's a content management platform whose flexibility and richness has grown on me over the past several months.  HDI's contact and membership data is stored in Microsoft CRM, so I wrote custom ASP.NET membership and profile providers that allow Sitecore to authenticate against CRM and read/edit relevant profile information.

While Sitecore is used to manage the general content, the blog posts and discussion forum content is stored in Jive. From a UI perspective, the Jive content fits seamlessly into the site. Under the covers, we're managing the blog and forum data using Jive's REST API.

Because HDI will implement additonal websites in Sitecore, I made the decision to put together a control-based framework. There's no code behind on the ASPX pages and ASCX user controls. Instead, the logic is built into controls that know their current context. Everything built for HDIConnect is being leveraged and re-used for the next set of websites. As our team has worked on the next set of websites, we've shown that strategy to be effective by delivering at a faster rate.

Speaking of the team, that's one of the best aspects of HDI. The other members of the business solutions team provided a great deal of support and assistance during the project. The marketing team and business solutions team work well together. Problems are solved with the attitude of working together for the benefit of the company. It's quite an enjoyable place to work.

There's been a couple of changes lately. One of them is this blog moving to Posterous. I haven't written a worthwhile post in...years..and many of them have stale content. So I'm ditching most of them and re-posting a couple that seemed to have some value.

More later.

Community Server's Single-Sign-On modules handle the case where:

• You have an ASP.NET website with an adjoining Community Server website
• Members log into your main ASP.NET website and you want Community Server to recognize that site's authentication of the member

What if members log into your Community Server website but not your main ASP.NET website? Over the past week, I've encountered two people who want membership to be handled by Community Server. But their main website needs to determine whether the member is authenticated via User.Identity.IsAuthenticated and User.Identity.Name.

It's possible to do so. I tested the scenario where the main website is at www.yourdomain.com and the community is at community.yourdomain.com. Both sites use forms authentication.

In order for www.yourdomain.com to see the authenticated user, you must make sure that two elements within the web.config file of each website are compatible.

In the <forms> element of the <authentication> element, the protection attributes must have identical values and the path attributes must have compatible values. In the <machineKey> element, the validationKey, decryptionKey, and validation attributes must have identical values. The following example shows the elements:

<authentication mode="Forms">
 <forms name=".CommunityServer" path="/" protection="All" timeout="60000"
    loginUrl="CS login Url" slidingExpiration="true" />
</authentication>

 <machineKey
  validationKey = " [your validation key]"
  decryptionKey = " [your decryption key]"
  validation = " SHA1" />

This is described with a little more detail in the .NET Framework Developer's Guide, topic Forms Authentication Across Applications.

This post falls into the category of "Solution for a technical issue for which I found no help on the Internet".

Overview

If you're using adhoc SqlParameters with a SqlDataAdapter and notice that calls to the SqlDataAdapter's Fill method take longer than expected, try using a typed SqlParameter instead of an adhoc SqlParameter.

Example of an adhoc SqlParameter:

adapter.Parameters.Add("@WMSReceiptID", wmsReceiptID);

Example of a typed SqlParameter:

SqlParameter parameter = adapter.SelectCommand.Parameters.Add("@WMSReceiptID", SqlDbType.VarChar, 64);
      parameter.Value = wmsReceiptID;
      adapter.Parameters.Add(parameter);

When using an adhoc SqlParameter, the ADO.NET implementation grabs schema information. In this case, it led to SqlAdapter.Fill taking 20 seconds to execute. I switched in the typed SqlParameter and execution speed returned to normal.

The gory details

Today I tested a bug fix on a search screen. The business layer builds a dynamic query based upon the search criteria entered by the user. With shock, I noticed that it was taking 20 seconds to perform the search. The request was carried out across a VPN connection to the customer's network, but it had never taken 20 seconds to execute this query.

At first I thought it was a dormant problem with the SQL that finally decided to wake up. But when executed via SQL Query Analyzer, the query completed in 1 or 2 seconds.

To isolate the problem, I threw the code into a console application. The code uses a SqlDataAdapter to fill a DataTable. The particular instance of this query had one parameter that was filled via an ad hoc SqlParameter.

Following is a stripped down version of the test code...

SqlConnection connection = new SqlConnection(Database.ConnectionString);
      try 
      {
        connection.Open();
        SqlDataAdapter adapter = new SqlDataAdapter();
        adapter.SelectCommand =
          new SqlCommand("SELECT ...", connection);

        adapter.SelectCommand.Parameters.Add("@WMSReceiptID", "[SomeRecordID]");
        DataTable table = new DataTable();
        try
        {
          adapter.Fill(table);
        }
        catch (Exception E)
        {
          Console.WriteLine("Error: " + E.Message);
        }
      }
      finally 
      {
        connection.Close();
      }

The test program also took 20 seconds or so to execute the source code line "adapter.Fill(table);".  For kicks, I removed the SqlParameter and hardcoded the receipt ID. Bam! The call to adapter.Fill returned in 1 second.

Hmmm. Why would using a SqlParameter cause slow performance? I've used them hundreds, if not thousands of them, with no slowdown.

I downloaded a trial version of Automated QA's AQTime and profiled the test application. AQTime reported a large amount of time in UnsafeNativeMethods/Dbnetlib::ConnectionRead. I used the Call Graph to backtrack. Once I reached method SqlDataReader.get_MetaData. I reasoned that the adhoc SqlParameter was causing ADO.NET to fetch the schema information and doing so was taking a lot of time.

I switched to a typed SqlParameter and performance went back to its expected level.