Upcoming Release of .NET Compact Framework CEDB Driver

[Andy Sjostrom]

It is a well-known and somewhat discussed fact that .NET Compact Framework does not include so-called managed capabilities to use the internal Windows CE object store. The Windows CE object store is sometimes referred to as CEDB, ADOCE or even "Pocket Access", even though Pocket Access has never existed as an application. With the older tools, some developers used and still uses the Windows CE object store to store application data. The lack of managed capabilities in .NET Compact Framework is an issue among this group of developers. Personally, I have stayed clear of the Windows CE object store because of its poor relational capabilities, performance and stability. I have used SQL Server CE and even local XML files instead. Meanwhile and since year 2000, I have tried getting my wish of having the Windows CE object store removed from Pocket PCs and instead get parts of SQL Server CE in place, through to Microsoft. I have a feeling it will eventually happen and if it does, it will be in line with what Microsoft does in other product areas.<br /><br />Apparantly, not everyone is like me and the company BA Systems recently announced the upcoming release of "the Qarina Pocket Access Driver for the .NET Compact Framework". According to BA Systems, this driver will benefit application developers by allowing them to use interfaces familiar to them from the full .NET Framework with the Pocket Access database format for Pocket PC handheld devices. Drivers and middleware with the purpose of supporting managed access to the Windows object store already exist in the for of, for example <a href="http://www.inthehand.com/index.php?page=5&show=1,2">ADOCE In The Hand</a> or <a href="https://www.odysseysoftware.com/purchase.asp?PRD=62569">Odyssey Software CFCOM-ADOCE Component</a>.<br /><br />It will be interesting to see what BA Systems has done with their Quarina Pocket Access Driver for the .NET Compact Framework! Read on for more details from the press release! <!><br /><br />"President and Co-Founder, William Mapp, noted that many Pocket PC application developers require the smallest footprint possible for their handheld solutions, yet want to begin building more robust and reliable applications using Microsoft's .NET Compact Framework. The omission of Pocket Access support was immediately noticed and major developers were left scrambling for a reliable substitute. Handheld developers have a challenging set of requirements to build the highest performance and memory efficient applications for such a restricted platform. "Qarina will allow developers to maintain a small footprint for their applications and still take advantage of the reliability provided by writing software for the .NET Compact Framework. In many situations, requiring the user to install the SQL Server CE database engine is not desirable because of the size and configuration requirements it presents. Qarina is a compact and high-performance alternative to SQLCE," Mapp said. Qarina is a driver component providing a rich API that helps decrease the time-to-market for database intensive Pocket PC applications. BA has presented a flexible and very attractive licensing arrangement that gives application developers the freedom to deploy the driver royalty free. Consumer applications and solutions that require wireless deployment are benefited tremendously by the compact size and automated installation of the driver. For desktop developers migrating to the Pocket PC, Qarina helps teams port their applications quickly to the handheld platform by supporting ADO.NET data access components that are intrinsic to the full .NET Framework. These features are part of BA's smaller, faster, smarter initiative that simplifies and enhances application development by using fundamental design processes. Qarina will be made available for beta testers towards the end of January and will ship in mid-February. The software is available from BA Systems and can be purchased from handango.com."

[darrylb]

I agree, I dont think that the old system has much of a future. Sure the SQL Server platform is big, but for corporate apps - so what?

A good alternative is XML as pointed out - these are a fraction of the size of SQL Server and work well (apart from the inability to relate tables :roll: ).

What would be really useful would be an API wrapper to write Pocket Excel files..... :grumble:

[Andy Sjostrom]

I agree, I dont think that the old system has much of a future. Sure the SQL Server platform is big, but for corporate apps - so what? ... :

Well, look at all PIM data stored in the Pocket PC such as contacts, appointments, notes etc. If the SQL Server CE storage engine could be isolated and implemented instead of the old Windows CE object store, the PIM apps would become snappier... and it would, for 3rd party app vendords, be easier to integrate with the PIM data. So, not only good for corporate apps! 8)

[Peter Foot]

What would be really useful would be an API wrapper to write Pocket Excel files..... :grumble:

I think you may be in luck here (although I don't know of when it will be released) - Chris Tacke has been working on a Pocket Excel API for .NET CF which will be released through OpenNETCF.org. Another option would be to export your excel data in CSV or XML format. For CSV we have a library at OpenNETCF.

Peter

[Peter Foot]

I agree, I dont think that the old system has much of a future. Sure the SQL Server platform is big, but for corporate apps - so what? ... :

Well, look at all PIM data stored in the Pocket PC such as contacts, appointments, notes etc. If the SQL Server CE storage engine could be isolated and implemented instead of the old Windows CE object store, the PIM apps would become snappier... and it would, for 3rd party app vendords, be easier to integrate with the PIM data. So, not only good for corporate apps! 8)

At PDC last year some of the plans for the next generation of devices were announced. See session MBL317 for details (http://msdn.microsoft.com/events/pdc/agendaandsessions/sessions/default.aspx)
A new data engine called eDB is being used to provide a standard datastore which will replace CeDb for Pim and other such system features and offer better performance and features. Looking at the descriptions of this and SQL Server CE 3.0 (also discussed at PDC) it appears they share a lot of functionality in common (ACID transfers, Encryption etc).

Peter

[empowermobility]

I don't normally chime in on these discussions, but I feel I have a counterpoint to contribute that seems to be falling by the wayside among developers these days.

8O 8O 8O

The notion that there is a possibility that the CE Object Store will be removed and replaced by the overhead of XML and SQL queries in its place absolutely scares me. Add the 20% reduction in performance by using 100% .NET and you've lost your users to slow queries and unresponsive UIs. Improve, don't remove!

8O 8O 8O

What's more is that I'm not sure what the animosity towards the object store is. I understand that it's lower level, but so is accessing the registry, dealing with the clipboard, or trying to work with a UI's device contexts for custom scrolling or complicated graphics. Win32 development was never meant to be "easy", just flexible and powerful. Remember that no matter the platform, whenever you put something on top of native APIs (like late binding VB), you will have a performance hit. Yes, faster processors and optimized code will help, but you still will have a hit.

Anyway, I personally have had nothing but positive results using the existing object store, especially when dealing with over 6000 records at a time, and I'm confident that I would never get the performance that I needed out of an XML doc and SQL query with data that size. Yes, the object store has only 4 sort orders (only one of which can be opened against a single database handle at a time), but clever engineering can work around that easily. Just open the database twice under each sort order and you're back in business. FWIW --- I've used up to three sort orders and it's fast.

IMHO, the problem here is that too many folks want to put huge desktop databases into the small working environment of Windows CE and not optimize their designs or take the time to do things right. As long as I can remember, even back in the day when Psion was the leader in PDAs, you were supposed to consider the PDA a desktop companion. Even now, MS designed their Windows CE memory architecture (as I explained above) to think like this, but still, many want that desktop power ...

For those non-developers out there, on a desktop PC we have unlimited resources basically. But on a Windows CE device we only have a total of 32 meg of RAM to work with (per app) ... period. :!: Regardless of the actual total RAM size offered when you purchase your PDA, a developer will always have this limitation. On top of that, you are only given a 1 meg workspace without tapping into the extra 31 meg using heap APIs and some sort of custom memory management for your app's data structures.

I guess my point is that I don't think PDAs are currently designed to deal with the overhead of complicated database models nor do we have communication pipes large enough and consistent enough across most real field-force areas to make these bigger tools useful yet. When? I don't know - I keep hearing it's coming but like everything else, it will take time.

In the meantime, I think we should all be thinking about doing the heavy lifting on the desktop and dumping a smaller more manageable data structure onto the PDA. I'd like to see folks build tools to make that easier and I think we'd be much better off. From personal experiences, this really has worked better for projects I've worked on and I'm currently working on designs for my own tool to do this.

Anyway, be smart, and think small. If you think small, then even when the pipes and performance opens up, your apps will run that much better. I'm all for improvements and easier tools to build apps, but don't introduce them at the expense of performance and user experience!

[Bill Gunn]

I don't normally chime in on these discussions, but I feel I have a counterpoint to contribute that seems to be falling by the wayside among developers these days.
&lt;snip>


Dittos with gold stars!

[Peter Foot]

I don't normally chime in on these discussions, but I feel I have a counterpoint to contribute that seems to be falling by the wayside among developers these days.

8O 8O 8O

The notion that there is a possibility that the CE Object Store will be removed and replaced by the overhead of XML and SQL queries in its place absolutely scares me. Add the 20% reduction in performance by using 100% .NET and you've lost your users to slow queries and unresponsive UIs. Improve, don't remove!



Microsoft isn't replacing the object store with XML and SQL overhead - the next generation will feature an improved engine but will still be accessible through API routines (there will be some differences due to new capabilities but largely these will be familiar to CeDb users). As already discussed the functionality is available for C++ and .NETCF through P/Invoke and wrappers already, Microsoft made a strategic decision not to provide a Pocket Access provider themselves as they saw Sql Server Ce as the database engine of choice for their anticipated .NETCF users.



What's more is that I'm not sure what the animosity towards the object store is. I understand that it's lower level, but so is accessing the registry, dealing with the clipboard, or trying to work with a UI's device contexts for custom scrolling or complicated graphics. Win32 development was never meant to be "easy", just flexible and powerful. Remember that no matter the platform, whenever you put something on top of native APIs (like late binding VB), you will have a performance hit. Yes, faster processors and optimized code will help, but you still will have a hit.

Anyway, I personally have had nothing but positive results using the existing object store, especially when dealing with over 6000 records at a time, and I'm confident that I would never get the performance that I needed out of an XML doc and SQL query with data that size. Yes, the object store has only 4 sort orders (only one of which can be opened against a single database handle at a time), but clever engineering can work around that easily. Just open the database twice under each sort order and you're back in business. FWIW --- I've used up to three sort orders and it's fast.

IMHO, the problem here is that too many folks want to put huge desktop databases into the small working environment of Windows CE and not optimize their designs or take the time to do things right. As long as I can remember, even back in the day when Psion was the leader in PDAs, you were supposed to consider the PDA a desktop companion. Even now, MS designed their Windows CE memory architecture (as I explained above) to think like this, but still, many want that desktop power ...


From experience of working in the newsgroups etc this is very true. Even SqlServerCe has its limitations, a good mobile application is one which complements and interacts well with its server/desktop equivalent, placing an entire systems database onto the device is rarely desirable. A well designed Pocket Access database can perform very well and offers a stable indexed data store with much lower overheads than other add-on engines.

I totally agree with your philosophy here that "small is beautiful", you have to think mobility when designing the applications not try to port a desktop application.

Peter

[Tom W.M.]

The Windows CE object store is sometimes referred to as CEDB, ADOCE or even "Pocket Access", even though Pocket Access has never existed as an application.
That's not true. Pocket Access:
http://webpages.charter.net/tomswallpapers/forumlinked/Pocket%20Access.png

Comes with all H/PC Pro units. :wink:

[Floodguy]

The Windows CE object store is sometimes referred to as CEDB, ADOCE or even "Pocket Access", even though Pocket Access has never existed as an application.
That's not true. Pocket Access:
http://webpages.charter.net/tomswallpapers/forumlinked/Pocket%20Access.png

Comes with all H/PC Pro units. :wink:


That was in the past. The newer HPCs on WinCe.net base do not have any longer Pocket Access/ADO/CEDB/etc. support nor drivers and apps. I personally use ADOCE wrapper from InTheHand (good work here Peter) and will stick with it. :D

[scorp1179]

I am trying to build a PDA program which will be using Pocket Access. I work with a study so we will not be getting our PDA's for a few more weeks. Is there anyway of building this program without the device? If so, how can I convert desktop access to pocket access in order to build the database and retrieve records and all that other good stuff. Please let me know. I'm in a huge time crunch!!


Heidi

[Flynn Arrowstarr]

Hi, Heidi.

What PDA operating system will you be using? And, what type of app are you developing?

If you're just trying to create a data gathering application which doesn't need to process the collected data, you could try XSForms and XSDesigner from Grandasoft (http://www.grandasoft.com/). The application stores information in a Pocket Access database which can be synchronized to the desktop. In their support forums is a method to synchronize the data to Access on the desktop (though it is a drawn out process).

If you're looking at something more complicated (data processing on the device) and you're using a PocketPC 2002 or earlier device, you can still download the eMbedded Visual Toolkit from Microsoft. eVB can use ADOCE natively. Of course, it's not supported by Microsoft and there are a number of workarounds you'll need to impliment around missing features, a few bugs, and some poor documentation, but there are a number of people on the newsgroups that can assist on that.

If you're using a newer device (CE.NET or Windows Mobile 2003), use the .NET CF. You'll have fewer problems developing and debugging the applications. If you need ADOCE (Pocket Access) support, check with Peter Foot about obtaining a license for his excellent ADOCE library.

Both eVB and Visual Studio .NET 2003 come with emulators so you can test your program out on an emulated device. You will want to test your code on the devices once you get them, as there are some differences between the emulators and the devices.

Hope this helps. Since this may be a little off topic, feel free to PM me if you have any other questions. :)

Flynn