Wednesday, March 12, 2014

SQL Server 2014 Install Experience

I recently starting working on a new project using Microsoft SQL Server.  I'm not new to relational databases, but I am new to SQL Server.   So, I'm going to do what any geek would do:  install it myself, poke with it a stick, and see what it does.  Let's get started.

First, google "microsoft download sql server".  I suppose I should use bing, but "bing" is not a verb, at least not yet.  From the google search results, select the SQL Server Express Edition - Microsoft link.

The Microsoft Express Edition page includes a download link for 2012 Express and a link to try SQL Server 2014.  There's a lot of experience on the Internet installing SQL Server 2012 or 2008, so let's try the 2104 version.  Click on Try SQL Server 2014 Express .  (If you're still running Windows XP, you will need to upgrade your Windows operating system or install SQL Server 2008.)

The next page describes five downloads in detail:
  • LocalDB (SqlLocalDB)
  • Express (SQLEXPR)
  • Express with Tools (SQLEXPRWT)
  • SQL Server Management Studio Express (SQLManagementStudio)
  • Express with Advanced Services (SQLEXPRADV)
We will use the last one -- it includes the database, the tools, and SQL Server Management Studio.

Click the Get Started Now button.

Sign in with you live.com or outlook.com id.  Complete the registration page, select Express with Advanced Services radio button, select 32/64 bit,  and select your language.

The download starts automagically.  If you don't have the Akamai Netsession installer, you will be prompted to install it. Click download to install it; after the installer is done, the download continues.

After the download is complete, find the file and execute it.  In my case, I'm running SQLEXPRADV_x64_ENU.exe.  The file is over 1GB in size, so it will take a moment to load.  Accept the default directory to load files, and get a coffee.  After a few minutes, the SS Installation Center opens.  Select the first option (assuming you don't have an older version), then accept the license agreement.




The setup continues, finally stopping at the Feature Selection screen.  Accept the defaults, which includes everything but the LocalDB.   Click Next. 




At the Instance Configuration, again take the defaults, noting the names: SQLExpress is the Named instance and SQLEXPRESS is the Instance ID.  Notice that the SQL Server directory and Reporting Services directory are both versioned 12, not 14.  These cannot be changed, but what's in a name?  Just click Next to continue.




At the Server Configuration Screen, set up the accounts.   Again, note and take the defaults.  Click next:




The Database Engine has four tabs: Server Configuration, Data Directories, User Instances, and FILESTREAM.   My server is just for learning purposes, so I'll use the default Windows authentication mode. 

The Reporting Services Configuration window has radio buttons Install and configure, or Install only.  Again, take the default Install and configure, and click next.

Now the Installation Progress window displays while the install completes.  This will take a while, grab a coffee and a donut. 


Finally, installation is complete.  On my older computer, installation took about half an hour.  But, the installer does all the work and the installation is easy. The Complete install screen lists some additional resources.  Note that unlike earlier SQL Server 2005 and 2008, the Microsoft SQL Server books are now online:
Now I'm ready to take a dive into SQL Server with even more resources at the SQL Server 2014 forums on MSDN, the training courses at www.lynda.com, or perhaps even a paper book.

Sunday, February 9, 2014

Documenting APEX Development

Most of us started programming using the Edit -> Compile -> Link -> Test cycle.  Whether we edited our source code in a simple editor like vi or in a development environment like Eclipse, we always had a source code file that we could print, or share with co-workers, or save in a repository.  The source code was a record of exactly how we solved a particular problem.

In declarative programming environments like APEX, we don't have any source code.  We develop pages by working through the APEX wizards in a browser window. Yes, we could export a page; but the resulting exported code isn't intended for mere human readers, and it's certainly not a road map to developing a similar page. Someone reading the export could not easily see what choices the developer made, or when the developer took the defaults.

So, how can we document what the APEX developer sees as they work through the widgets?  We could take a lot of screen shots and paste them into an MS Office or OpenOffice document.  Many of the APEX wizards display a page that would take four or five screenshots to document; pasting all the snapshots into another document is a pretty clumsy process.  We need a way to capture the whole browser page in fell swoop.

Printing the browser page does a good job of document everything on the page, but rather than printing to paper, we can print to the Microsoft XPS printer.   XPS is a device-independent document format describing the layout and properties of a document using XML.  The Microsoft XPS printer prompts the user to save the XML document in a file, and these files can be viewed using a XPS viewer.

The XPS files aren't source code, but in a declarative programming environment, they're the next best thing. Now you never need to wonder again how you defined a control, configured security, or defined a region. Just print the definition as an XPS file. Be sure any text areas are large enough to display all code that you entered, and then print the page, choosing XPS as your printer.  Save the XPS file with a descriptive name, and you will have saved a record of how you defined the object.  Now we have file that we can view later, share with co-workers, or save in a repository.