 |
Chris De Herrera's Windows CE Website |
|---|---|
About |
|
| By Chris De Herrera Copyright 1998-2007 All Rights Reserved A member of the Talksites Family of Websites Windows and
Windows CE are trademarks of
Microsoft All Trademarks are owned |
ADOCE
By Terence
"Dr. CE" Goggin
Copyright 2000, 2001 Terence Goggin
Version 1.00 Revised 4/20/01
[an error occurred while processing this directive]
Topics
1. How do I use ADO tables from within C/C++?
2. How come my BLOB/Memo fields aren't showing up in my CDB
tables after I've copied a table to the device?
3. How come accessing my data on a CF card is so slow?
4. Is there a desktop-based MDB to CDB file converter that
doesn't require a connected CE device?
5. How do I distribute a pre-converted CDB file with my
application so that the user doesn't have to do a sync?
6. My desktop application uses a secure MDB. How can I
synchronize it?
7. I would like my Access application to perform its own
synchronization. Can this be done?
8. I'm trying to access a CDB in the emulator, but it's not
working. What's wrong?
9. What data/field types (wav, bmp, etc.) are supported in
CDBs?
1. How do I use ADO tables from within C/C++?
The easiest way to do this is through some classes
provided by Vos Corp at the link below. Yes, you can
access ADO tables "natively"; i.e., without this wrapper,
but it's just not worth it. This wrapper is as good as they
get.
For more information: http://www.voscorp.com
2. How come my BLOB/Memo fields aren't showing up in my CDB tables after I've copied a table to the device?
There are two possible answers here...
1. When copying your database down to the device, you
used the default field mappings. ActiveSync removes fields
like this (BLOB, Memo) by default. Just specify the fields
explicitly and this should resolve the issue.
2. Your fields are actually being copied down, but they're
empty on the device. Fields larger than 64K are not
supported by ADOCE. You'll have to write a routine to
copy the contents of these fields out of the database
manually and put them on the device as multiple files
or in some custom single-file format.
3. How come accessing my data on a CF card is so slow?
Reading from a CF card should be comparable (for most
databases, anyway) to reading from the object store.
However, writing to a CF card takes considerably more
work at the OS level -- one write is actually about 3 or 4
separate operations. So, while you and your users might
not notice at first (especially if your tables are small),
you certainly will notice as your tables begin to grow.
Even worse, there's no real quick fix for this; you'll have
to use the object store for really good performance with
writing.
4. Is there a desktop-based MDB to CDB file converter that doesn't require a connected CE device?
No. While there are file converters for many of the CE file types, this isn't one of them.
5. How do I distribute a pre-converted CDB file with my application so that the user doesn't have to do a sync?
The best (if not only) way to do this is to...
1. Convert an MDB to a CDB using the ActiveSync UI.
2. Using your desktop's FileExplorer, browse your "mobile device" until you find the CDB file you just created.
3. Rename your CDB so that it has a different file extention. ("CD_" will do just fine.)
4. Using FileExplorer, copy that renamed file back to your desktop. (The renaming circumvents ActiveSync from converting it back to an MDB.)
5. Rename the file back to a CDB.
You now have a CDB that is distributable.
6. My desktop application uses a secure MDB. How can I synchronize it?
This research comes to the FAQ courtesy of Tom Orlofsky, who had a similar question.
-------------------------------------------------------------------------------------------------
I have spent the evening experimenting with various security settings on
trivial Access dbs to see if I could determine what Active Synch needed securitywise
to succeed in converting the file to a *.cdb setting up a synch. I have come to
the following conclusions:
1. Admin needs to be able to have "read design" capability on a table for
any fields in the table to be exported to the device. This is the minimum
level to create a *.cbd file on the device. Admin doesn't have to own the
table or administer the table.
2. Admin needs to "own the database" in order for active synch to create two
system tables in the desktop db. The first one it tries to make is called
"MSysCeConflicts". If Admin does not have database ownership then Active
Synch will not establish a link between the db on the desktop and the file
on the device. The following shows up in the log file: "[Microsoft][ODBC
Microsoft Access Driver] You do not have the necessary permissions to use
the 'MSysCeConflicts' object. Have your system administrator or the person
who created this object establish the appropriate permissions for you. Table
'Your Discs' cannot be synchronized."
I would have thought that a lesser level of power would have been sufficient
to set up an active synch in case 2. Condition 2 is pretty fatal for any
Access application that is trying to maintain any level of security. The
Active Synch developers appear to be unfamiliar with Access security
practices as weak as they are. The Microsoft ODBC driver permits one to
login to secured Access database by passing the login name and password in
the ODBC connect string. I find no way to pass these attributes in the ADOCE
API.
Credits: Tom Orlofsky, orlofsky@orlofsky.com
7. I would like my Access application to perform its own synchronization. Can this be done?
No. ActiveSync will try to open the table in exclusive mode, which means
that the Access application can't be open & running when the sync is
performed. Therefore, it can not initiate the sync process.
Credits: Tom Orlofsky, orlofsky@orlofsky.com
8. I'm trying to access a CDB in the emulator, but it's not working. What's wrong?
There are a few possibilities...
1. There is a bug in the emulator that limits the size of CDBs to about 300K.
2. General problems with the emulator and CDBs. To quote Christopher Tacke,
"In my experience, using a CDB in emulation is sketchy at best. Often times
what works on the device will return an error in emulation. This is
especially true when doing a lot of data INSERTS. For this reason I often
recommend laying out the application in emulation, but then use a TCP/IP
connection to the device via a LAN to do further testing and debugging.
Using a LAN connection is just about as fast as the emulator (with the iPaq
it's actually faster), and far less prone to emulator quirkiness."
Credits: Christopher Tacke
9. What data/field types (wav, bmp, etc.) are supported in CDBs?
CDBs support blobs just like MDBs do... However, there are a few restrictions you should be aware of...
1. By default, these fields are *not* copied down to the CE device during a conversion.
You must explicitly specify any & all blob fields that you want to be copied. (When sync-ing a CDB
for the first time, you are presented with a treeview listing the tables and fields of the MDB. You must
expand this list and make sure the blob fields are checked.)
2. CDB blobs are bound by the same limitations as CEDB blobs, which is to say 65K bytes.
Other than that, you can use blobs just like any other field.
[an error occurred while processing this directive]
Terence Goggin's DoctorCE.com site - Custom Windows CE development/consulting services.
Return to Chris De Herrera's Windows CE Website
Questions? Comments? Suggestions? Email Terence "Dr. CE" Goggin.