Ok I admit it, I’m a developer and configuring access to SQL Server is not my bag (baby). SQL 2005 had a nice big Surface Area Configuration button than just allowed access from clients, so I ignored what it was doing, pressed it and got on with my work. However, SQL 2008 seems to be have been targeted at me because it no longer has such a backdoor and forced me to find out what I should do. So I thought I’d write it down for others who prefer to search the web rather then read the documentation <oops>,

First off you need to open the SQL Configuration Manager and check your favourite protocol is enabled, for me that would be TCP/IP. Double click that and select the IP Addresses tab. You’ll notice in there a list of possible IP addresses and ports for SQL to listen on. You can, if you maintain your (mine) lazy tendencies simply change the setting from dynamic to static and plug in port 1433. When clients attempt to connect to your server they attempt to use 1433. Now this isn’t supposed to be a good idea (no idea why – you’ll see why later) so stick with dynamic ports. Now this means that SQL will listening on some port but you’ve no idea what as it may change each time the server starts. So you must start the SQL Browser Service, this acts as the go-between and “tells” the client what port to use. So there you are, you should now be off and running. But why not use 1433? I thought the idea was slow those pesky hackers down, but if you have to open the Browser Service then what does that achieve? Something I need to look into, when I have the time, when I have the time, when I have the time…..

It’s still early days for the W3C Widget, but the idea of been able to write a little application that I can run on numerous devices and platforms without requiring any changes is interesting (well I spose you could call that Adobe Air, maybe even my beloved Silverlight at a stretch – but even they requires an additional plug-in). So knowing that in reality they’d be difference I set of downloading various SDKs. However, I hit a number of installations problems all of which I’m sure are down to dodgy installers, beta software and 64bit Windows – not a clever combination I admit. So I grabbed trusty WinMobile and started on that first. The first issues was getting Visual Studio to sync up with the emulators. No chance, there is no project for widgets you have do everything by hand. So here is my very quick guide to get you working;

1. Install Win Mobile 6 SDK refresh
2. Install Win Mobile 6.5 Dev Toolkit – you’ll now have the emulators available to the device manager
3. Create a blank web site
4. Add content – see

http://windowsteamblog.com/blogs/windowsphone/pages/getting_2D00_started_2D00_with_2D00_widgets.aspx

http://msdn.microsoft.com/en-us/library/dd721906.aspx

5. To test I used a great little util http://widgetemulator.codeplex.com/
6. Then to try it out for “real” create a shared folder in the emulator pointing to your .wgt file, and browse to it from the PDA folder browser