Pocket PC and SQL 2000

  • Thread starter Thread starter STom
  • Start date Start date
S

STom

I have just started learning about Pocket PC/SQL CE development.

Are there links that someone could point me to to help me understand things
such as:

1. If I have a pocket pc application, I can still use SQLClient for SQL
Server 2000, but can I actually connect to a SQL 2000 database?
2. If I can connect to a SQL 2000 database, what happens when I am
disconnected?

I have two scenarios that I am dealing with here...

1. I have a SQL CE database on the device and I need to merge or synchronize
with a SQL 2000 database via internet access (not docking).
2. I have a SQL CE database and I need to extract the data and send it
wireless to an web service.

I'm just not sure where to gather the information that I need.

Many thanks for any assistance.

STom
 
1) Yes. You'll need to add a reference to the System.Data.SqlClient.dll
though.
2) The same thing that happens when your desktop app isn't connected.
Remember in ADO.NET the whole paradigm is Connect and Kill. If you use
Connected methodology ie, cmd.ExecuteReader, cmd.ExecuteScalar
cmd.ExecuteNonQuery then ideally you should do your thing and disconnect.
If you use Disconnected Methodology, ideally the dataadapter will
automatically open and close the connections for you. Either way you don't
want to leave stuff open.

A common approach for situations on a PDA (because in most cases you can't
guarantee connectivity all the time) is to all your PDA to work in both a
connected and disconnected mode. Once you query the DB you have your data
stored in memory locally. You use this all you want and don't need a
connection again until you decide you want to send the data back to the db.
If you never want to send it back to the db..fine. However, assuming you
will at some point, and assuming that your app might close, you'll probably
want to serialize your datasets using DataSet.WriteXML(@"\Storage
Card\Whatever.xml"); for instance, but specify that you want to use the
Diffgram option. Otherwise you'll effectively have a stateless tier which
will probably be much less useful if at all. Anyway, once you use WriteXML
and you ahve your file, you can use ReadXML in the inverse fashion. From
there, your dataadapter will be able to know what's changed and be able to
submit updates/deletes/inserts etc.

Now, if you are using SQL CE and merge replication, then the change you make
can be sumitted locally and you don't need to have a connection back to the
main db (nor use the serialization method I just spoke of) in order to
temporarily persist your changes when you aren't 'connected' to the main SQL
SErver. When you get back, you fire the replication and viola.'
 
William,

Thanks for all the info.

I think the way my client is leaning, they want to have web services on the
backend to receive the data in an XML or maybe even a flat file format, so
essentially, I guess I could just use the WriteXML to generate the datafile
that I need to send.

However in this case, I'm not sure the 'Diffgram' option would really mean
anything since the web service and the server it is on is not going to be
running .Net or SQL Server.

It is more common to just write your own XML document structure or to use
the WriteXML method of the dataset?

Thanks again.

STom
 
Back
Top