SQL Server Mobile

  • Thread starter Thread starter evan.ruff
  • Start date Start date
E

evan.ruff

Hello,

I have been programming for my Motorola Q. I have the Compact Framework
2.0 installed. The utility uses the SQLServerCe library and does a
little lite DB stuff in the course of performing its tasks. The
question I have is about the distribution.

Do I have to seperately installed SQL Server CE over and above the
Compact Framework 2? The utility is around 15K and does some very light
logging. It seems overkill to ask my users to install both CF2 AND SQL3
(about 1.5MB) just to run this little guy.

Do I have this correct? I was under the impression that SQL Server
Mobile was already in the CF2? If not, can I use the old version that
is already on the device? Also, is there a different solution other
than full-on SQL Server implementation?

What DB engine does Pocket Outlook run on?

Thank you for the clarification.

E
 
You do need to install support for SQL Mobile as well as CF 2 - it is not
already included.

How much data will you be logging? Would XML be a better choice for you?
 
Thanks Ginny,

I could be pulling 20,000 records down so was looking at RDA - already use
in in an app using SQL Server CE 2.

I did find and install Sqlce30setupen.msi.....

I traditionally have tested the server agent by typing in
http://10.0.0.33/SSCE20/sscesa20.dll
and then get
"SQL Server CE Server Agent" in the browser Window.

I've set up a virtual web called SSCE30 in IIS and point it to a directory
containing sqlcesa30.dll
but when I type in http://10.0.0.33/SSCE20/sqlcesa20.dll it just gives me an
Assembly Not Loaded error and does not work. How do I test my SQL Server
Agent in SQL Server 2005 Mobile??

Thanks
Harry
 
Ginny,

Thanks for your response. The app really dosen't need much, if any SQL
support. I believe XML might be a better choice, but have never really
used it as a data storage/retrieval medium (ha, I've just always used
SQL!). Is there any sample code/best practices available about how it
applies to CF?

Thanks,

Evan
 
Evan,

I don't know if there are an official best practices since most people do
indeed use SQL like you have. I have built apps that record data by writing
out a line to a text file as the data is entered (rather than using
DataSet.WriteXml which rewrites the entire xml file each time), thus
providing protection from somebody resetting the device along with great
performance, so you might consider that. They're basically delimited text
files with a CRLF at the end of each record, so they're very easy to parse
using String.Split(). The easiest way to do this I've found is to create a
business class with properties for the fields of data you want to collect
and that has its own Load and Save methods that know how to write and
hydrate those properties. The other advantage of this approach is that if
you decide later you want to use SQL after all, you just have to change
those two methods.
 
Back
Top