Geeks With Blogs
Next Gen Developer Web x.0, conferences and more...

OK so I have been having a play with SQL Mobile (Recently re-named with the CTP as SQL Everywhere) for working on a device from a CF card.  Now there is a nice little note in the MS documentation for SQL Mobile:

"SQL Server Mobile installation works only on the main memory of a device. If an attempt is made to install SQL Server Mobile on SD/CF card, then SQL Server Mobile installation does not work."
SQL Server 2005 Mobile Edition Books Online

Then I found an article about how you can actually install SQL Mobile on a Storage Card.  Granted it is a bit of a hack.  The info below was sourced from 

Moving SQL Mobile to Storage

The SQL Mobile is not installed in its own subdirectory under Windows - all DLL files are in the \Windows directory but they are easily recognizable: all start with sqlce and end with 30.

If you are using the OLE DB provider, unregister sqlceoledb30.dll before copying all DLL files to \CF Card\Windows. After copying, don't forget to register this DLL again.

Also move the isqlw30.exe file from:

\Program Files\SQL Mobile\EN


\CF Card\Program Files\SQL Mobile\EN

besides recreating the Program Files link, you will also have to correct the entries in:


And that's it! (apparently... I am yet to give this a try... )

Anyway this begs the question should anyone really be using SQL Mobile on a CF or SD card.  I am guessing from the Microsoft documentation note that they don't support it (MS please feel free to clarify this).  The question is why they advise against it?  Is this a performance issue?  A reliability issue on the software... or does in write to the storage card too often to make it a viable option to use?  Or even worse does it go over the boot sector of the card and trash the card completely?  If anyone at Microsoft would like to explain the reasoning I would be more than happy to know.  It would be interesting to understand why because I can see a lot of uses for storing the data from an SQL Mobile DB on an SD card especially if you want to take it out of one mobile device and just pop it into another to run it... 

Comments feedback and info on CF and SD cards and Databases more than welcome!

Posted on Monday, July 31, 2006 10:59 PM Mobile , Embedded | Back to top

Comments on this post: SQL Mobile with SD and CF Cards: Good Idea or Not?

# re: SQL Mobile with SD and CF Cards: Good Idea or Not?
Requesting Gravatar...
In fact, you can forget about isqlw30.exe altogether as that is just the Query Analyser.

I can understand why MS don't support SQL/e on a storage card. It's because of the limited read/write lifespan of the cards. UPDATEs and INSERTs are very intensive I/O operations. However, there surely must be something they can do to reduce this intensity. Maybe buffer the changesets to persistent storage (to secure against data corruption from power loss), then if the changeset hits a size limit or a time span has past, write out to storage card.

There's also another gotcha with SQL/m, er, SQL/e: You can't use a database stored in the virtual storage card through shared folder feature on the emulator. It throughs intermittent "SQL Mobile made an unsupported request to the host operating system" exceptions.
Left by Neil Cowburn on Aug 01, 2006 7:34 AM

# re: SQL Mobile with SD and CF Cards: Good Idea or Not?
Requesting Gravatar...
Hey Neil,

Thanks for your input. Your thoughts were the same as mine on the no of writes. That was my initial thought... but then I thought about how I have used SQLite and we don't have any real issues with it coz we are in control of when we write to the storage. Since we don't have that level of control I guess it just eats up the writes (even on the industrial cards... :S)

Also thanks for the hint on the emulator!
Left by Sarah on Aug 01, 2006 1:38 PM

# re: SQL Mobile with SD and CF Cards: Good Idea or Not?
Requesting Gravatar...
I have given up on using SQL/e right now... Just not ready to work with... The SQL tools build a db ok, but if you try use it within you VisStu project it just doesn't belive its a real db...


I'm sure it'll get fixed. But whilst it not. I'll stick to XML. Lighter and faster at the mo!

Then, going back to the orginal post, you can store the data where you like :)
Left by keni on Aug 02, 2006 10:53 PM

# re: SQL Mobile with SD and CF Cards: Good Idea or Not?
Requesting Gravatar...
I'm sure I'm missing the point, but why do you want to install the runtime to the storage card? Surely it would be better to install them to the device's internal storage? There's certainly no need to do this to get a database onto a storage card - you can specify any path you like in your connection string.

I suppose if you were going to run your application from the storage card and not want to install anything, it might make sense, but if you're trying to support a .NET CF application, you'll have to install the CF runtime to \Windows anyway. You certainly can't rely on the ROM version of the runtime being any use - the early versions in Windows Mobile ROMs were bug-ridden enough to be unusable. We've always installed to the memory object store because traditionally the read speed of Flash has been poor. That's less of an issue with Windows Mobile 5.0 devices since you don't get a RAM-based filesystem on most devices.
Left by Mike Dimmick on Aug 06, 2006 1:01 AM

# re: SQL Mobile with SD and CF Cards: Good Idea or Not?
Requesting Gravatar...
Sorry Mike but you are missing the point. Lets just say someone wants to install it all onto a storage card and there is no solid state storage on say a bespoke device... then what do you do... hmmm... the issue is that they have built this for a CE system and yet they don't support all CE system configurations with SQL Mobile (Soon to be everywhere - i.e. Everywhere won't work everywhere! Possibly a small miss marketing issue!)

BTW I'm not using it on Windows Mobile devices.. so the ROM is not an issue here. I am using it on Win CE 5.0 Devices.
Left by Sarah on Aug 08, 2006 10:22 PM

Your comment:
 (will show your gravatar)

Copyright © Sarah Blow | Powered by: