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!