Wednesday, February 27, 2013

Demonstration of a jQuery implementation of the JavaScript Promise Pattern

In preparation for my talk at the last Chicago SharePoint Developers User Group meeting, I spent some time putting together a few lines of code to demonstrate jQuery reading a web service and asynchronously rendering data from the web service in a grid. The JavaScript and jQuery portion of the code is shown here for reference for anybody that wants to use it.

The grid used in this example is a jQuery grid called ParamQuery. You can find out more about it here: I simply downloaded the minified JavaScript library for paramquery and, after reading a little of the documentation, wrote the appropriate code to format my data into the table. You can see the implementation of the paramquery grid in the code below.

In the video below I demonstrate the grid. I click on a row and it loads a picture from LinkedIn using the column with the LinkedIn picture url. The grid is resizable and draggable. I then demonstrate adding a row to the SQL Azure database, reloading the page, and seeing the new data.

The jQuery grid gets the data from a completely unrelated data source. The data source has a back end Azure database with a web service that exposes data in JSON format. In the video, I simple add a row to the table and the web service does the work of exposing the data in a format I can read with my jQuery

Here is the JavaScript and jQuery for the page demonstrated in this example (in its entirety). Note that the code uses the jQuery implementation of a JavaScript Promise pattern (.deferred). It is not necessary here but was used to illustrate the pattern.

Instruction Guide for Installing SQL Server 2012 SP1 for SharePoint 2013

This instruction guide will walk you through how to install SQL Server 2012 SP1 for SharePoint 2013 on Windows Server 2012.

  • You have a clean install of Windows Server 2012 x64
  • You are installing SQL Server 2012 in a disconnected environment. That is, the SQL Server has no internet access. Note that the instructions don't vary much if you are installing in a connected environment.
  • You are doing a basic installation with minimal Reporting Services, Analysis Services, or BI tools, for example. You can always add those later.

Step 1

Install .NET 3.5 on Windows Server 2012. This is simply a Windows Server 2012 Feature. If you don't do it now, SQL Server 2012 will try to install it for you. It may fail, however, because SQL Server 2012 installation media doesn't include .NET 3.5 and it may not be able to access the appropriate installation source.

Step 2

Once you have installed .NET 3.5, start the installation of SQL Server 2012 SP1. Select the "Installation" link on the left hand side of the installer and then select "New SQL Server stand alone installation or add features to an existing installation"

Step 3

Next the setup support rule checker will run. If everything passes, it will look like this (note that I clicked "View detailed report" to look at the pretty green check boxes).

Step 4
Enter the appropriate license key if necessary

Step 5

Check the box to accept the license terms. In a disconnected environment, I do not send feature usage data to Microsoft.

Step 6

In a disconnected environment, you will not be able to download product updates from the installer and you will get this snazzy error message. Click Next

Step 7

Select the basic components to install. The Database Engine Services is obviously the reason we are installing this in the first place. So select "Database Engine Service". I usually install the complete management tools on the SQL Server (although this is not necessary) so that I can easily manage things from the server if I need to.

Note that in the image below, it says "Windows feature(s) to be turned on: Microsoft .NET Framework 3.5" You will see this if you did NOT install .NET 3.5 as I recommended in step 1.
If you did NOT install .NET 3.5 as recommended in step 1, you will also get this warning on the next screen. It clearly states that it may not be able to access Microsoft .NET Framework 3.5 (although it will try), which is why I recommend installing it in the beginning yourself.

If you did install .NET 3.5 as recommended in step 1, you should see a screen like this at this point:

Step 8

At this point, you will pick the named instance and the instance root directory. I always setup my SharePoint SQL Servers with a Named Instance. Note that you do not normally need to change the Instance ID. That will populate for you based on the Named instance. This is also where you specify the instance root directory. Normally you want this to be your data drive.

Step 9

In this step, you specify the service accounts that both the database engine and the SQL Server Agent will use. In the screen shot below, I am using the default settings. But you actually want to specify a domain account. For details, please see Todd Klindt's SharePoint 2013 service account suggestions here

If you were following Todd's suggestions, you would use YOURDOMAIN\sql_server for both the Agent and the database engine. Note also that the installer defaults the SQL Server Agent Startup Type to Manual. I usually set that to Automatic, however, because I am usually scheduling some kind of job in the environment I am working in. If you plan to schedule SQL jobs in SQL Server, set the Startup Type for the SQL Server Agent to Automatic

Step 10

The default SQL Server 2012 Collation is shown in the screen shot below. Typically, you do not want to use that collation, especially if you are upgrading a SharePoint 2010 environment.

The safest bet is to set the collation Latin1_General_CI_AS_KS_WS.

You can find more information about it here:

In order to set the correct collation, select the customize button and check the appropriate boxes shown in the second screenshot below.

Step 11
On the next screen, you will select either Windows Authentication Mode or Mixed Mode for SQL Server. Generally, unless you have a reason to do otherwise, select Windows Authentication Mode. At this point you can also add SQL Server Administrators.
Step 12
Assuming you are following all of the appropriate recommendations and requirements for your environment, you will want to specify the appropriate default locations on the Data Directories tab. In the screen shot below, I have everything point to C:, but typically you would have it broken down as follows:
DATA Drive: User database directory (this is where SharePoint databases will go. In this case, SharePoint is the user)
TEMPDB Drive: Temp DB Directory and Temp DB log directory.
LOG Drive: User database log directory.
Step 13
I typically do not enable FILESTREAM unless I am using Remote BLOB Storage.
Step 14
In a disconnected environment, I do not send Windows and SQL Error Reports to Microsoft
Step 15
One more rule check:
Step 16
Click Install:
If you have any additional notes or suggestions, please let me know!