Linking SQL Server to an Access database

Posted on by

Even if importing an old Access database to SQL Server is pretty easy using available tools, this might not always be the optimal solution. Linking an old Access mdp file to your SQL Server enables you to gradually move old legacy databases and systems to leverage the power and stability of a server database as you can leave the old dependencies untouch while implementing new ones to use the server.

Setting up an Access database as a linked server on a SQL Server requires a number of steps. For those in a hurry and not wanting to read the whole article, this is what you need to do:

  1. Install the 64 bit database driver
  2. Configure the Access Database Engien provider settings
  3. Allow users full access to the temp directory of the SQL Server service account
  4. Setup the linked server

First thing to do is to get the Jet database drivers installed on the server. As Access first did not support 64 bit operating the drivers are not available out of the box. Don’t worry, you will not need to restart after installing this.

Then go to Server Objects — Linked Servers — Providers and you should see the newly installed “Microsoft.ACE.OLEDB.120.0″ driver. Open it’s properties and check both “Dynamic parameters” and “Allow inprocess”.  Provider properties

Then complete this  first step by enabling the ‘Ad Hoc Distributed Queries’ setting with the the following command:

sp_configure ‘show advanced options’, 1;
GO
RECONFIGURE;
GO
sp_configure ‘Ad Hoc Distributed Queries’, 1;
GO
RECONFIGURE;
GO

 Now you will avoid getting errors when trying to browse or access items in the database.

SQL Server needs to use the temp directory of the SQL Server service account for handling the linked server. For things to work and you to avoid any “Unspecified errors” you need to make sure also the account accessing the linked server has access to that same temp directory (the security settings of the link seem to have no affect on this). The quick and dirty solution to this is to give the account(s) or all users access to the temp directory under the application data folder under the account profile. The proper solution is to:

  1. create a new temp folder for the service account (or use c:\temp)
  2. change the TMP and TEMP environment variables of the service account to point to the new folder — this will require restaring the server for the changes to take effect
  3.  setup a group with the accounts that need access to the database to give it full control over the folder.

As a final touch before setting up the actual linked server you might need to take the time to define a SPN for the service account in cases when the database file is not on the same server as the SQL Server.

Finally go to Server Objects — Linked Servers and add a new linked server. Give it any name you like to identify it and select Office Access Database Engine as the driver. The define the connection parameters as follows:n

  • Product name can be anything you like, usually the type of the database e.g. ACCESS
  • Data source defines the path to the database file
  • Provider string can be used to define additional connection string parameters

Linked server properties

Make sure to check that the settings on the Security page are has you want to have it. Then click on OK.

Now to make sure the linked server actually works, first open the context menu of the new linked server and select Test Connection. Then browse through the structure down to the tables to see if SQL Server is able to display you the objects in the database. If no errors are displayed the link is now ready and you can go and get your self your well deserved hot beverage.

The best JavaScript MVC framework

Posted on by

I’m a great believer in frameworks as they provide a SOLID and well tested infrastructure for you solutions. Modern web apps are base on a almost excessive amount of JavaScript on the client side and REST services on the server side. There are a lot of frameworks that support this and the challenge for developers is to figure out on which one to invest their time on. Even if  the teams behind the products encourage to mix these, the reality is that  doing so will only result in hacks – in other words the framework needs to be complete.

So, on what horse did I decide to bet on? The answer is AngularJS.
Why? Let me telly you:

  • It tells a lot about a framework if the most basic examples reveal many features but are also easy to understand
  • Unlike the jQuery+Knockout+whatever combos it provides a complete framework which not only guides developers to setup the app in a certain way but also supports testing by design
  • It is a product of a big company (Google) but unlike Kendo it is 100% free making it easy to to take into use and to find developers already familiar with it. Not to mention that it is actually possible to find reviews without any commercial BS.
  • Unlike e.g. Ember it is a mature framework with a good online documentation and active community.
  • It provides templating by allowing to extend the standard set of HTML/DOM elements with your own components. Personally I find this approach most intuitive and clear.
  • The apps are based on controllers, directives, filters and services. There is a inbuilt support for dependency injection.
  • Unlike Knockout there is no need to use special observable object types in your model to get the data binding to work.
  • The Chrome and Angular teams have worked together to provide a browser add-on to help debugging.
  • It has no (inbuilt jQuery lite) dependencies on other frameworks unlike backbone, ember and most others.

Time will show if my investment pays off :)

Worth reading:

SharePoint Web Part Basics

Posted on by

All web parts are based on the same basic ingredients. When I started developing on my first web parts I did some extra work to find out the best practices. This post is meant to work as a simple reference and to answer some of the questions I had when I first started.

What web parts events should I use?

There are many different opinions on this. This is mine:

  • Never put code in the constructor as it might be called even if the object is later never used
  • In the OnInit initialize any controllers etc. you might have
  • In the CreateChildControls method create your controls, but don’t populate them. Note that it is a common practice to define all the controls and the wepart layout in a separate control class to keep the web part clean.
  • In the OnPreRender load the data into the controls and setup any async task you might need (they will be executed next)

How to register JavaScript?

There are many ways to include JavaScript on a page, the right one depends on your need. To include a script to to be executed directly after page load use the RegisterStartupScript combined with the ExecuteOrDelayUntilScriptLoaded (SOD) or _spBodyOnLoadFunctionNames.push functions:

public static class SharePointScriptHelper
{
public static string ExecuteOrDelayUntilScriptLoaded(Control control, string script, string after)
{
string script = string.Format("ExecuteOrDelayUntilScriptLoaded(function(){{{0}}}, '{1}');", script, after);
ScriptManager.RegisterStartupScript(control.Page, typeof(Page), "Script_" + control.ID, script, true);
}
}

SharePointScriptHelper.ExecuteOrDelayUntilScriptLoaded(this, "alert('Hello world!');", "SP.js");

The first mentioned takes care of the correct load order of scripts.

To include e.g. a library that is not meant to be directly executed use e.g. the RegisterClientScriptInclude method:

ScriptManager.RegisterClientScriptInclude(this.Page, typeof(Page), "MyScriptNamespace", ScriptFileUrl);

The point in using the ScriptManager is to avoid having the same script included multiple times, hence the key parameter in e.g. RegisterclientScriptInclude. The class offers a lot of functions that are worth taking a closer look at.

Note that is is a good practice to wrap you scripts in a “class”/namespace to avoid e.g. function name collisions with other scripts.

To easily include the web part id in your inline scripts you can use the ReplaceTokens function of the web part class to do this. It will simply replace tokens like e.g. _WPID_ with the correct property values.

How to include CSS on a page?

CssRegistration css = new CssRegistration();
css.After = "corev4.css";
css.Name = Settings.StyleSheetFileUrl;
this.Controls.Add(css);

I have not yet had a chance to test SharePoint 2013 to see if it works to refer to the corev4.css also in that version.

Where to define configuration parameters?

The web part definition file (yourwebpart.webpart) is definitely the only correct place. This way they the properties are fully customizable by the site owners when necessary.

Never store passwords in any file as they belong in the secure store service. You can prevent property values from being exportable for a simple way of hiding them.

How should I define my layout?

The most flexible and powerful way is to use XSLT for the rendering. You can implement it your self or inherit the DataFormWebPart class.

Where should I put the CSS, image and other files?

Put them in the appropriate SharePoint mapped folders. Always create a sub folder for you web part and give it a unique name e.g. based on the namespace of the main class.

How to do logging and debug?

Use the inbuilt framework. The most elegant solution would be to write your own service class deriving from the SPDiagnosticsServiceBase but note that it will need to be registered at deployment time.

public static class SPDiagnosticsServiceExtension
{
public static void WriteTrace(this SPDiagnosticsService service, string message, string categoryName, TraceSeverity severity)
{
SPDiagnosticsCategory category = new SPDiagnosticsCategory(categoryName, TraceSeverity.Unexpected, EventSeverity.Information);
service.WriteTrace(0, category, severity, message);
}
}

Usage

SPDiagnosticsService.Local.WriteTrace(ex.ToString(), "Web Parts", TraceSeverity.Unexpected);

I strongly recommend enabling the Developer dashboard and using the SPMonitoredScope to help optimize the performance of your web part.

That’s all for now, more to to come later.

Don’t go (Entity Framework) code first

Posted on by

Code first (Entity Framework) allows developers to forget about SQL, deploy schemas and have everything under source control. As long as you don’t think about the future all is just fine and dandy. But the life cycle of a solution and especially it’s database is only starting when it is first developed. The new Fluent Migrations framework and SQL Server Data Tools have got me thinking about what in the end would be the tooling that will retain its value also later in the life cycle.

Using code first getting started is easy and the initial deployment is close to zero effort. Unfortunately this is where the sunshine ends and the dark clouds appear. As time goes buy, the production database gets full with masses of business data and other systems start relying on all the views and schema. Some monday morning your boss asks you to to add a couple of columns, remove some depricated ones and maybe do some renaming while your at it. To be able to test your changes you of course start by copying a part of the production data to to the test server. Now then fun starts! You first edit your (code first) entities classes, then fire up SQL Server Management Studio to edit the database and finally give the changes a thorough testing. To finish off you prepare SQL scripts to get the production database updated. As this is all manual work, you find your self thinking that life could be easier - and so it can!

Imagine coding your schema first with Fluent Migrations, then letting the standard Entity Framework to generate your entities based on the database. Now, no mather what changes come you can always do them first by code, then let Visual Studio update the entities and finally deploy you changes without leaving your IDE. All the promises of code first, without code first. Oh happy days!

Dilemma of code first

Make your Windows 7 a little bit safer

Posted on by

Virus scanners and firewalls are like vitamins, they help you stay healthier but they don’t prevent you from getting sick. This other day I found the Antivirus virus rampaging on my laptop. Vulnerabilities in browser add-ins is the most common reason for viruses to get on your computer.  In my case there where suspicious files both in the Java and browser cache.

After removing the troublemaker with the scanner I had and running some online scanners just to make sure, I did what I should have done a long time ago to make my Windows a little bit safer:

  • First a made a separate admin account and removed the rights from my standard account. Windows will now prompt me for the admin password when necessary. Experts claim 80% of the know viruses will be stopped just by doing this. I had done it on my XP (never had a virus scanner on that old computer) but forgot about it when I upgraded.
  • I updated my Java to the latest version and then I disabled Java both from the Java console and the browsers. I also disabled the Java cache just to be sure. Best option would of course be to just remove the whole thing but I was not sure if I would need it later.
  • Then I installed Chrome as it’s claimed to be the safest browser and set it as default.
  • As a final touch I disabled the JavaScript support from my PDF viewer and disabled the Chrome internal one has I could not find any option to do the same there. I then used some safe PDF scripting examples available on the internet to test my configuration.

The evolution of web development

Posted on by

Now over 13 years back I worked as a professional web developer. In those times JavaSscript was just something used to validate forms and anything else (e.g. toggling the visibility of a element) was considered fancy and labeled as DHTML. Few weeks ago I got a email from a co-worker having problems with including inline JavaScript in a ASP.NET razor page – this got me on memory lane.

Back in the days the code to open a popup window could look like this

<p><a href="javascript:window.open('http://www.google.com','mypopup')">Open google!</a></p>

This not only displayes as a scary link in the browsers status bar but also is useless in browsers not running JavaScript. So quite quickly the developers shape up and started putting the code in a separate JS file and using the events available:

function popitup(url) {  window.open(url,'mypopup'); }

<a href="http://www.google.com" onclick="popitup(this.href);return false;">Open google!</a>

This was fine for many years. But then it became modern to write nonobtrusive code (keeping the scripting and visuals separate). Even if this in practice requires a lot more code frameworks like jQuery make it easy.

window.onload = function() {
var myPopupLink = document.getElementById('myPopupLink');
if(~myPopupLink) myPopupLink.onclick = function() { popitup(myPopupLink.href); return false; }
}

<a id="myPopupLink" href="http://www.google.com">Open google!</a>

What next?