• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 563
  • Last Modified:

vb.net cf question about data storage options

our customers are foresters.  many of them are independant and work from home.  most have limited computer skills.  getting a forester 500 miles away by phone (with no IT dept) set up with IIS, the linkage for sync via IIS, MSDE/SQL Server, SQL CE, ActiveSync, .Net framework, ADOCE, InTheHand, and our app is not a punishment i'd wish on anyone.  there must be a simple, reliable way.  it'd be good for big companies but the opposite of what is needed for a "shrink wraped" solution for a "basic" user.  frankly, we can't believe this is the way microsoft expects this to be done...

now the design choice question.  this question is mostly about what kind of database would best suit our needs.  underneath is an open question whether we should be using a different development environment to meet our needs.

objectives:  make a reliable, reasonably fast, database application that can be installed by non-technical people with limited phone support.  the desktop application uses MS Access for data storage and its schema should be changed as little as possible.  it needs to be able to run on as many  kinds of handhelds as possible.  the application is for collecting data about trees in the forest.  our desktop app manages the data exchange (about 10 tables).

we wrote an application with vs .net 2003 in vb.net cf.  we used ADOCE 3.1 and InTheHand with a CDB file for storage.

now with vs 2005, InTheHand won't work anymore so we need to choose an alternative.  

we could continue with vs 2003 but the deployment headaches never seem to end with ADOCE.  about 2/3 of the machines we try it on we can't get it working.  pretty dismal.

we'd like to use VS 2005 to rewrite the vb.net (cf) app for this job.

we're not afraid to store data as binary like we do in palm.  if we were to do that, though, it would sure be helpful if there were a lean database system that would allow storage/retrieval of binary data like that so we didn't need to write a complete database system ourselves.  each palm record is a string of bytes and you read/write that as necessary.  very fast and actually surprisingly reliable.  VB.Net seems to be seriously limited when it comes to working with binary data like that.  still looking...

we need to be able to sync it to our MS Access 97 database.  after a week of fooling with trying to satisfy ActiveSync's needs, we finally found and perfected the use of DEVICETODESKTOP and DESKTOPTODEVICE to exchange data.  (looks like activesync syncs tables in alphabetical order with no regard to referential integrity; disappointing because that makes it unusable in the traditional way like dragging a database to the handheld!)

right now, if we could get ADOCE working, we'd have an app we can distribute.  apparently right now we have nothing because:

1.  adoce 3.x doesn't seem to work on lots of different machines.  haven't been able to solve the problems.
2.  InTheHand doesn't work with VS 2005.  it looks like InTheHand is a dead product.

choices seem limited
limiting factor:  our (mature) desktop application uses an MS Access 97 database.  we don't want to change that.  (this eliminates iAnywhere)

limiting factor:  we don't want the "SQL CE + IIS + SQL Server/MSDE installation/configuration" nightmare.  (this eliminates SQL CE so far as i know)

limiting factor:  we'd like to use VS 2005.  maybe we could adapt our previously written vb.net cf app to work with whatever we choose for storage.

limiting factor:  whatever db system we choose, we must be able to sync it with the desktop.  writing one of those activesync service providers.  one of my colleagues tried that and never succeeded.

limiting factor:  there are all these different flavours of windows mobile.  vb.net seems a logical choice so i don't need to enter another world of nightmares where i must maintain two (maybe more) copies of the application so we can distribute to all of these diverse types of systems.  not to mention different processor types, etc.  if we could only do 1, i suppose we should do pocket pc instead of hpc2000, win ce 4, ... whoa, i scarcely know what i'm talking about there.  hence our attraction to vb.net instead of eVB.

CEDB seems like a way we could store the data in binary format like is done in Palm.  saves us from writing a database storage system.  BUT it seems CEDB may not be supported on all windows mobile versions?  does CEDB have a "future"?  don't want to repeat the ADOCE experience (that wasn't much fun).

are eVB and eVC essentially "dead end" products?  (they appear to be since they don't appear to ever have received any "love".)  have wondered about using one of these products but that'd be like having nails for breakfast.  iron in my diet is good but...  next thing i know, apps made by them won't run.

XML on the surface sounds like a solution but it seemed too slow for the volume of data and # of fields we were storing.

maybe i should actually be using VS.net to make a traditional VC++ app for this job.  then use _____ for database access.

there in an interesting article:

            remote data, sql server, sql server ce, and iAnywhere seem unsuitable for our needs.

we're lost.  can you point us in the "right" direction?  any comments or advice would be appreciated immensely!

thank you!
  • 2
1 Solution
I understand your dilema about choosing the right storage scheme for your pocket pc applications.  I am sure I don't have an answer for you but hopefully can spare some comments that might help you out.  

I don't know all of the details but a co-worker just tried Windows Mobile 5.0 and the new active sync and he said it no longer converts Access databases to pocket access databases.  I apologize I haven't tried this myself but I can tell you we develop mobile applications so this will break some of our apps.  We also used ADOCE in the hand.  I can tell you, since I have been there I have been a big fan of getting rid of that stuff.  It is .net, why are we using old ado?  

There are lots of ways to store the data on the pocket pc, unfortunately the pocket pc is limited on resources unlike the desktop.  I am sure sqlce is a great database.  I have not used it, so I can not give any data on that.   VS 2005 now supports serialization on the pocketpc.  This was a nice added feature because you could (in theory) create objects that match your data scheme and just serialize them to the device as a binary file.  Your limitations however would be in how large the file would be (although probably not bigger than the space in sqlce or access, and the time you are willing to wait for the file to deserialize.  With this type of solution, a very large file may take a bit of time to deserialize but then, once put into the objects again would be fast.  

You could use Datasets and then write them out as xml.  Again, the downside is the time it takes to read the dataset back in from the xml.  Large amounts of data take a little while.   This just depends on what you consider large amounts of data.  The positive to a dataset over a serialized object is that if you change your object you might have problems deserializing the old object.

Another option would be XML files.   This option I think really depends on your functionality to whether it would be a good choice or not.  I actually have a product that runs solely on xml for a back end.  But with the way it works on the pda, it works fine because I don't search for specific items or anything like that.  I just fill out or update a record.  I have found that xml is not hard to work with but again, it is based on your functionality of whether it would work.

About evb and eVC,   I am actually working right now with Embedded C++ even though I am in a 100% VB.net shop.  The reason for this is that I need to write a windows service for the Pocket PC.  Unfortunately, you can only do that in EVC,  it is not supported in .Net.  I have not used EVB but work with someone that has and think they prefer .net much better.  

Things to watch out for with VS2005.  I am not sure that the 2.0 compact framework is supported on OS's before 2003.  I have not tried them on a pocket pc 2000 or 2002 device but believe it will not work.  If you are looking for something that can reach more clients and this is the case then .net 2003 would be a better choice (research the 2.0 limitations before deciding).  

I hope some of this helps out a little.  It is very difficult to say which storage is right and what technology is right without being tied closely to the application.  It is easy for someone that doesn't have to implement the solution to say use ______.   Alot depends on the time users are accepting to wait during different parts of the application.  Do they want to wait longer at start up or wait longer in the middle of the app.  

Good Luck
mikepjAuthor Commented:
thank you for your comments!  it looks like we can get away with using XML.  it'll take about 25 seconds to load the xml file but it will work.  

FYI, using VB.NET on CE is easier than Code Warrior with Palm but it sure is slow.  on palm someone had a database with 1000 records and you wouldn't know it by the way the application behaved even on an ancient, dusty palm III!  that'd easily kill a windows CE VB.NET program.
mikepjAuthor Commented:
here's a progress report...

XML, while it worked, was clearly too slow.  loading even with a small database was too slow.

have since settled on Codebase (http://codebase.com/).  here's why you'd use codebase:

- it's fast, especially if you put in a bit of effort.
- you can read/write the entire record (except for memo fields) as a chunk of binary data.  that'll make beaming fast and easy.
- the database format on the desktop and CE are identical.  that makes it easy for your desktop application to reach into the CE machine and copy in/out databases for exchanging data.
- it works with CE, Delphi, visual studio, etc

one downside is that it doesn't support all platforms on the handheld.

another downside is that it's a bit spartan to use...but you can expect that when it's designed to be efficient and fast.

all-round, it's a pretty good solution.

i hope this was of some benefit for someone.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now