SQL Mobile 2005 – Editing Table Data

In SQL Server CE 2.0 it was always painful to create the mobile database, and populate the data. However, with SQL Mobile 2005 and VS.NET 2005 Microsoft has come a long way to making the SQL Mobile database much easier to manage. While creating a new database is pretty well document, editing the table records is more obscure.

While developing the database is handled easily in the Microsoft SQL Server Management Studio, editing the database records requires VS.NET 2005. The “trick” to editing the database table is to use the Server Explorer (View->Server Exploer) in VS.NET to open the table for editing.

The first set is to add a Data Connection to add your mobile database to the project. This can be done by selecting the Data Connections option in the Server Explorer and choosing on the “Add Connection…” option in the pop-up menu. This will launch the “Add Connection dialog which you can use to specify the location and password of the database. For this example I am using the NorthWinds.sdf mobile database.

Add Connection - Northwinds

Once the Data Connection is successfully added you can now use the Server Explorer window to examine the various properties of the database. In order to open a table to edit, you must first expand the Table tree to see a list of all of the tables that are in the current database.

Server Explorer - Northwinds Database

Finally by selecting the table and choosing “Open” for the pop-up menu (right mouse) you can open the table and start editing. In this case I chose the customer database table.

Edit the Customer Table

SQL Mobile 2005 – Error: Not Enough Storage is Available

Here’s another in a long list of cryptic error messages. In this case I am developing a local database component for our SNAPRetail applications and on opening the database for the first time I get a SQLCEException with the message “Not enough storage is available to complete this operation”. Initially, I thought it was a problem with my database, but it is after a little searching I found a post (http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=895861&SiteID=17) on the Microsoft Technet forums that describes the problem as a “DLL Squeeze” and to open the connection to the database at the start of the appliation.

A little more research reveals that the DLLS that are being loaded are sqlceqp30.dll, sqlcese30.dll, sqlceer30en.dll, sqlceme30.dll which are the minium required for SQL Mobile to run.

Intermec Scan Configuration

I received a CN3 today to try out with our snapRetail applications and at first it seemed like things weren’t working correctly with scanning, but it soon became apparent that it was just a matter of scanner configuration.

Virtual Wedge

Virtual Wedge ConfigurationThe first problem I had was ironically the problem of scanning ocurring when I it should be disabled. By default Intermec has enabled a keyboard wedge, “Virtual Wedge”, that accepts barcode data from the scanner and generates key events to simulate that the data has come from the keybooard. This is easy enough to disable, just go in to Intermec Settings (Settings->System->Intermec Settings) and disabled the Virtual Wedge and after copying the Intermec Data Collection dll over to my program the terminal scanned only when I wanted.

While I guess it’s ok to enable this by default, though it has always been a pet peeve of mine to call applications barcode enabled, when all they are doing is using a keyboard wedge. While this “works”, it creates an incredibly clumsy interface for barcode scanning that keeps the scanner always enabled, and puts barcode data anywhere the keyboard focus is set. This may be “ok” for consumer devices, so I can put barcode data in my Word document, but for “real” applications it is really a bad idea.

What bothers me even more is when people claim that they have a barcode-enabled handheld program, when all they’ve done is turn the keyboard wedge on. Perhaps the worst case of this “mis-advertising” I’ve seen was during the keynote of the 2006 Microsoft Embedded Developers Convention where they demonstrated creating a “barcode enabled application” to a roomful of developers when all they had done was use a keyboard wedge. Perhaps if they would have attended my session they would have been able to do it the real way ;-).

Automatic Symbology Conversion

Once I got back to being able to control the scanner, and configure the Symbologies, I went in to the Item Lookup application to try scanning some barcodes. Everything seemed to be scanning fine, except that whenever I scanned a UPC code I was receiving thirteen digits (with a leading zero) instead of twelve as I was expecting from a UPC barcode.

UPC A xmit as EAN 13This gets in to the whole world of automatic barcode conversions. In order to support the requirements of different industries and governments there are a broad variety of similar, but slightly different symbologies. This means that for a US-based retail , the developer must take in to consideration EAN8, EAN13, UPCA, UPCE0, and UPCE1 barcode symbologies. In addition, there are also UPC Supplemental barcodes (extra information often used on books for ISBN numbers), check digits, and expansion of EAN8 barcodes to EAN13.

In this case, the default configuration that Intermec has selected is to convert everything to an EAN13 symbology which in my case caused the problem. This is also configurable through the Intermec Settings application, and disabling the conversion “UPC A xmit as EAN 13” solved my problem. Alternately, this can be configured programmatically through the Intermec Data Collection API but I like keeping these types of paramaters configurable by the end user.

However, the lesson is that even if the hardware vendors decide to make it easy for the application developer to use barcodes, its still important for them to understand what “magic” is happening under the covers.

Intermec Scan to Exit

We had another very curious incident, this time on an Intermec terminal. Each time the terminal scanned a barcode our application would immediately exit.  No warning, no exception, nothing but an immediate exit.  And it wasn’t even a complicated application, just a simple prototype.

What made this even more curious was that it didn’t happen on all of our Intermec terminals and hadn’t occurred in the past with our other customers.  A few more details will make the problem a little clearer.  First of all we are developing in .NET CF 2 with VS.NET 2005 and our SNAP application framework.  The Intermec 760B terminal is running Pocket PC 2003 (OS 4.51 Premium with PSM 3.93.1 for 32MB Flash) and the Intermec 2.4 IDL.Intermec 700 Series Terminals

So it was a matter of rolling up our sleeves and getting down in to the bowels of the source code.  Initially we suspected that there was an exception in the scanner dll causing the application to abort.  We tried the usual tasks such as walking through the code (difficult since scanning is event driven), and catching exceptions on invocation instead of where they are caught, all to no avail.  Finally, it was a matter of controlling the scanning to catch the error, where we found a Windows Message conflict, essentially programmatically triggering the scanner to control the execution in the debugger.

Apparently Intermec has implemented their scanner code using messages and happened to assign the same Window Message ID (WM_USER+1 =  0x401) that we were using for exiting a sequence of forms (in this case out of the application).  And that’s the end of the application.

So what does that mean.  The first thing one could argue is that a system object like this should not expose the window messages to the application, or at least not use one that is quite so common. And I’d think you’d have a pretty good argument there. 

So the simple solution is that rather than using WM_USER as our Message ID base, we could use a value that is unique within the system.  The easy way to do this is to register the window message with the OS and request a unique id.  Simply use the method:

[DllImport("CoreDll.dll", SetLastError = true, CharSet = CharSet.Unicode)]
static extern uint RegisterWindowMessage(string lpString);

static uint WM_MY_MSG = // use RegisterWindowMessage to ensure unique

Of course this isn’t 100% perfect since you can still have people using the same string to register their message.  To take it the next step you can create a GUID, but I think that’s getting a bit much.  Just use a reasonable unique name and everything should be fine. 


Symbol's New WT4070/WT4090

Recently I’ve been doing quite a bit of work with Symbol’s new wearable terminal, the WT4070 and the WT4090, the long awaited upgrade to Symbol’s original DOS wearable terminal the WSS1060. For those unfamiliar with these terminals, these are wearable terminals typically used by warehouse and distribution center workers such as UPS, FedEx, etc. The WT4070 is the currently shipping version that support 802.11 b/g, and the WT4090 will support 802.11 a/b/g. It is actually the same unit with software changes to handle some regulatory hurdles with the radio.

For the last few months, I’ve been working on migrating the SVTP terminal emulator I wrote at Symbol, from the old DOS terminal to Windows CE (SVTPCE) for one of our larger customers. Symbol does ship the WT4090 with a license for another terminal emulator, but our customer preferred having a version that was drop in compatible with their existing terminals, which used the original SVTP, and could be customized to meet their exact requirements.

ARD_SVTPCESince I’ve been working with this new terminal, I thought I’d give a short review of the new WT4090 terminal and some tricks for working with this terminal.

Overall the WT4090 is a great terminal, and is a long awaited addition to the Symbol product line. It’s lightweight at only 12.6 oz. and has a very nice display and keyboard layout. The WT4090 will be available in two keyboard layouts, a “2-tap” keyboard that functions like the legacy WSS-1060 did, and a “3-tap” keyboard that operates more like a cell phone keyboard.

However, the biggest feature is that you now have a full Windows CE 5.0 operating system strapped to your wrist or belt which opens up a huge number of possible applications. Initially I see this product as a technology refresh for the current WSS1060 users who will mostly use it for warehouse and distribution centers, but down the road this could easily be used for many other types of field force applications where it would be helpful to not need to carry the terminal around. And with the belt option and voice capabilities the options expand even more.

The WT4090 also comes with two scanner options, the RS-309 Scanner and the RS-409. The RS-309 scanner is very large and bulky for a wearable scanner and I wouldn’t recommend it, but the RS-409 is a very nice device that compares favorably to the older RS-1 and SRS-1. Also, the scanner can be connected on either side of the terminal to allow for either left or right-handed users.

Display (not Touchscreen)WT400 w/ RS-309
The display is a nice 320 x 240 landscape pixel addressable QVGA. It is sufficiently bright for working indoors, but would be difficult to use in an outdoor environment. Overall a pretty nice display.

One of the first things that I noticed was, like the MC1000, the WT4090 does not have a touch screen!!! When asked, Symbol told me that this was a design decision to help improve the terminal’s ruggedness in the wearable environment. Since the terminal is meant to be worn on the wrist or belt, they felt that having a touch screen would reduce the ruggedness of the device and receive stray mouse events.

However, I find that the lack of a touchscreen on a Windows operating system is difficult to work with. After a while I was able to navigate fairly well with the keyboard, but there are some functions that I was never able to access. Also, its hard to get past the habit of trying to push the buttons on the screen when looking at a windows environment. In a production environment this is probably ok since the end users will not need to navigate the Windows CE Shell, but as a developer or administrator it can be quite painful.

There are two ways to get around this “problem”. First, Symbol has provided USB keyboard and mouse drivers for their terminal which you can use to connect directly to the WT4090 (through the cradle). However, it requires an odd cable, a Mini USB A to USB A Female connector, which is apparently commercially available but not at any of the normal electronics stores (Radio Shack, CompUSA, Best Buy, …).

The second option, is to run the Microsoft ActiveSync Remote Display program to connect to the device over a regular ActiveSync connection. This is the choice I took, since it didn’t require finding special cables, and as a developer I needed to use the USB connection to debug the application. See my article on ActiveSync Remote Display for CE 5.0.

One more consideration when developing applications for the WT4090 is the memory configuration. The device has 128MB of RAM, and another 64 MB of flash available in the /platform and /application directories that Symbol uses for installing applications.

The WT4090 does not provide any slots for an external memory card. In general this is not a problem since the terminal is targeted for a warehouse environment which is continuously connected, but will prevent this terminal from being used in other field force applications.

New Bluetooth Stack
This terminal uses the StoneStreet OneBlueTooth Stack which Symbol is now also using on the MC9094. While in theory switching between the various BlueTooth implementations shouldn’t be a problem, it is when they implement different programming APIs. So for us this means migrating our BlueTooth implementation from using the Microsoft Socket interface to the API provided by Symbol on devzone.

Also note that Symbol is not providing the BTExplorer GUI on this terminal so all BlueTooth access must be done using the software APIs.

Software Development
Development for this terminal is essentially the same as any of the other Symbol handheld terminals. Since it is a Windows CE 5.0 device it is best to do your development in Visual Studio 2005 to be able to deploy your applications.

Symbol provides the folowing set of SMDKs for wearable development (available in devzone):

Startup Applications on Symbol terminals

There are two ways to cause an application to run during the Symbol startup of the terminal, either using the Symbol Startup Program Registry Keys or as a Startup Application in the Symbol Startup Folder. You should pick only ONE of these choices.

Symbol Startup Program Registry Keys

Symbol has created a set of registry keys that can be used to create a controlled launch of programs during the boot sequence. By setting these parameters, and using the Microsoft wceload command, it is easy to orchestrate the applications that are run during startup.


Where ProgN can be set to any value between 1 and 20. However, be careful since some of the values are reserved for Symbol applications, and may be used by other applications.

Reserved Values:

  • Prog4 Symbol .NET Class Libraries
  • Prog5 Symbol AirBeam Abboot.exe
  • Prog7 Symbol AirBeam Abstart.exe
  • Prog10 Symbol Printer Drivers

Another nice part of the Symbol Registry is the options that can be set for each of the programs. This allows you to have real control over applicationstartup.

Registry Options:

  • Name Application file name with full path spec (string)
  • Command Application command line parameters (string)
  • Continue Block or not block, 1 = do not wait for program to finish
  • ColdBootOnly Run on cold boot, 1 = run on cold only (dword)

While these commands can be used for launching any program, they can also be easily used to install CAB files as well with the Microsoft application. By using Microsoft’s wceload utility you can easily install CAB files from the command line with several helpful options. See the wceload page for details on the command line option.

An Example:


; Load .NET CF 2
“Command”=”/delete 1 /noaskdest /noui windowsNETCF2.CAB”

“Command”=”/delete 1 /noaskdest /noui windowsSVTPCE.CAB”

; Run SVTPCE – Example, uncomment to use.
; Per Symbol the “preferred” method is to use the ApplicationStartup
; directory, but you can’t control the order
“Name”=”Program FilesSVTPCE_FDXSVTPCE”

Symbol Startup Folder

The other main choice is using the Symbol Startup Folder. In this method, you simply create a “.run” file which provides the options for running an application, and installing the file in the “ApplicationStartup” directory. Symbol says this is the preferred method.

A “.run” is a text file with two lines. The first line is the complete name of the executable file (with full path information), and the second line is an optional command line argument to be passed to that executable file. For instance, if the run file contains the command:

Program FilesSVTPCESVTPCE.exe

It will launch the SVTPCE application. However since the execution order is unspecified, if the program needs to be installed first, you will either need to load the CAB files with Registry parameters, or create an application to load the CAB files and run the application.

Pros and Cons of These Methods

Each of these methods for controlling application startup have their pros and cons, and this must be carefully considered when setting up a configuration.

Registry Method: The key advantage of the Registry Startup method is the absolute control that can be had with the startup of the applications. This allows specifying if the applications only runs at cold boot, whether the application is run synchronously or asynchronously, and the exact sequence of the programs. All of which provide a huge amount of control for the user.

Despite all of these advantages, there is also a downside to the Registry Startup method. Since there are a small set of registry values allocated these must be managed very carefully. This is fine if you are integrating a custom system, but can be very dangerous with a product that must be able to interoperate with other programs.

Application Startup Method: This option provides the simplest method for starting applications, but what you gain in simplicity, you lose in control. Unlike the Registry method there are no guarantees on the sequence of the applications that are launched. Likewise, you aren’t able to control how and when the applications are launched. Any such control must be provided in a custom program for your application.

Although you lose control in the launch sequence, it is the simplest method for applications that don’t require special treatment. Also, it is the best method for products that must be able to launch in any environment.

Other references:

ActiveSync Remote Display for CE 5.0

Microsoft’s ActiveSync Remote Display program, which comes as a separate download with the Windows Mobile Developer Power Tools, has always been a nice tool for viewing and demoing applications. 

However, I’ve been recently working on a project on the Symbol WT4070 which does not have a touch screen and only a limited keyboard.  While its possible to access pretty much everything through the keyboard, it’s not easy.

That’s where the ActiveSync Remote Display program makes a huge difference, but unfortunately it does not natively recognize CE 5.0 devices.  However, if you copy the remote client “cerdisp2.exe” on to the terminal, everything starts working again, and you have a nice remote desktop to work from.

So here are the steps:

  1. Download the ActiveSync Remote Display program (EmuASConfig.msi) from the Windows Mobile Developer Power Tools site and install.
  2. Navigate the installation directory (C:Program FilesWindows Mobile Developer Power ToysActiveSync_Remote_Displaydevices).  This directory contains files for all of the platforms that ARD recognizes.  Find the device that best matches your terminal, for most devices this will be “wce400armv4”.
  3. Create an ActiveSync connection to your terminal.
  4. Copy the program “cerdisp2.exe” to the “Windows” directory of your terminal.
  5. Launch ActiveSync Remote Display from the Start Menu.  Note: The message “ The OS or CPU of this device is unknown to this application” will be displayed.  This can be safely ignored.

And then use it like a normal window application as in my SVTPCE application.