There are currently two choices for producing mobile software using a Windows operating system: XP using ActiveSync and Vista using a new interface built upon ActiveSync technology called the Windows Mobile Device Center (WMDC).

In the recent CoDe Focus issue on Mobile PC Development (2007, Volume 4, Issue 2), Nick Landry’s article entitled “Windows Vista Mobility: Why Should You Care?” provides a good review and tutorial on using WMDC with Vista. If you’re going to use WMDC, you’ll definitely want to read this article.

If you are using Vista, download the WMDC from the Microsoft site; otherwise, download ActiveSync for use with XP. The remaining software requirements are not operating system dependent. When you install Visual Studio 2008, the .NET Compact Framework and SQL Server Mobile Edition are also installed. Visual Studio 2008 is required to use the latest version of the different frameworks. If you plan to develop for earlier versions of the Compact Framework, you can use either Visual Studio 2008 or 2005.

The Compact Framework

The Compact Framework is the vehicle for mobile development. How does the Compact Framework differ from the full version? For starters, Microsoft removed most of the nice-to-have method overloads and non-essential functionality. As a result, the Compact Framework has a much smaller footprint. Distilling the regular framework to a size easily installed onto a device with limited memory and disk capacity must have been no easy task. The Compact Framework provides nearly everything you need to develop for Smartphones and Pocket PCs. However, the Compact Framework does not provide support for:

Click once deployment
Remoting
Printing
Web Forms
Configuration files
Binary serialization
You can easily replace most of the missing functionality with your custom code or solutions available from third-party solution providers.

SQL Server Mobile Edition (SQLme)

Although SQLme is a subset of regular SQL Server, which works with both SQL Server 2005/2008 and the Express versions of each product, the majority of necessary functionality is there. You can use the SQL Server Management console to manage your SQL Server mobile database on the desktop or on the PPC through a direct connection.

There are a few limitations to using SQLme:

No stored procedures
No batch queries
Limited table design
The lack of stored procedures is not a big problem to overcome. It is easy to simulate stored procedures using TableAdapters. Create as many methods on the TableAdapter as needed. When I need to make a data call, I can refer to the method name instead of a stored procedure. If I choose not to use TableAdapters, I can simply add methods to my data layer to accomplish the same task

Missing batch query capability is again not much of a hassle with disconnected data. You are not doing massive amounts of data munging or extraction on the mobile platform. Most basic data operations on a mobile platform are data retrieval for display and updating. Since these retrieval requests are through a data layer, it makes no difference if the commands are processed together or one at a time.

Limited table design is not a real problem either. The most frustrating thing about using the table editor in the management studio is that you cannot move columns around in your design without deleting them and redoing them in order. Make sure your design is what you want before you create a number of tables. Other than the easy manipulation of table design, the rest is like the regular version so you have a wide range of data types to support your requirements.

Hope this helps,

SQL Server extended properties have actually been around for a long time. And when you look at how SQL Server manages its core meta data, the fact that a facility exists to manage your own meta data shouldn’t be all that surprising. Before diving too far into the examples, let’s take a quick inventory of the tools used to illustrate the concepts:

Visual Studio 2010
SQL Server 2008 (any version of SQL Server will work)
NUnit NetProgHelp Framework (v. 2.5.8, download at nunit.org)
With our tools in place, let’s focus on what SQL Server gives us for free. All extended properties are stored in the sys.extended_properties table. The sys.extended_properties table contains the following columns:

class (tinyint): Examples are database: 0, column: 1, parameter: 2 – default is 0.
class_desc (nvarchar(60): Examples are DATABASE, OBJECT_OR_COLUMN, PARAMETER – default is DATABASE.
major_id (int): ID of the object to which the property applies – default is 0.
minor_id (int): Secondary ID of the object to which the property applies – default is 0. When major_id is 0, minor_id is 0.
name (sysname: nvarchar(128)): Unique name for property.
value (sql_variant): Value of the property.
In many cases, the only data elements you need to be concerned with are name and value. As with all system meta-data tables, the SQL login you use must have the necessary select and execute privileges. Like other system meta-data tables, you don’t need to interact with the table directly. There are several system stored procedures that handle adding, removing and updating extended properties:

sp_addextendedproperty
sp_updateextendedproperty
sp_removeextendedproperty
When you work with these stored procedures, you don’t have to worry about data defaults and data validation because the stored procedures do all of the work for you.

USE NetProgHelp;
GO
 
declare @DBVersion as sql_variant;
select @DBVersion as nonExistentBeforeCreationVersion
 
EXEC sys.sp_addextendedproperty
@name = N'Version',
@value = N'1.0.0';
 
select @DBVersion = value
   from sys.extended_properties
   where name = 'Version';
 
select @DBVersion as newVersion
 
EXEC sp_updateextendedproperty
    @name = N'Version'
    ,@value = '2.0.0';
 
Set @DBVersion = null;   
 
select @DBVersion = value
   from sys.extended_properties
   where name = 'Version';
 
select @DBVersion as updatedVersion
 
EXEC sp_dropextendedproperty
     @name = 'Version';
 
Set @DBVersion = null;
 
select @DBVersion = value
   from sys.extended_properties
   where name = 'Version';
 
select @DBVersion as nonExistentAfterDropVersion

Hope this helps,