Wednesday, November 30, 2005
WTL 7.5 Released
The latest version of WTL (7.5) has been officially released on sourceforge. According to Nenad Stefanovic: This is the first release on SourceForge.net, as the part of the Microsoft Shared Source Initiative. WTL 7.5 features the support for Visual Studio 2005, enhanced support for Windows CE development, and new classes and bug fixes and enhancements.
Thursday, November 24, 2005
SQL Server Mobile 2005 on MSDN
SQL Mobile has a new home page on the MSDN Mobile Developer Center. There, you can find articles, downloads and other resources on SQL Mobile. Cool stuff!
Wednesday, November 23, 2005
Localized .NET Compact Framework 2.0 Redistributable
Microsoft has just released the localized versions of the .NET Compact Framework 2.0 Redistributable. These are available in the following langueges: Chinese (Simplified), Chinese (Traditional), English, French, German, Italian, Japanese, Korean, Portuguese (Brazil), Spanish. You can download these from this link.
Tuesday, November 22, 2005
Saturday, November 19, 2005
Sunday, November 13, 2005
Post-TechDays interview
Here is my interview after TechDays in Lisbon (Portuguese language only).
Ricardo Figueira's Blog (no, we are not related)
Ricardo Figueira's Blog (no, we are not related)
Friday, November 11, 2005
RAPI and Windows Mobile 5
When the first Windows Mobile 5 devices started to hit the market, some of my customers tested Data Port Wizard on them and found out that it would not work. There is a documented workaround on MSDN but one of my customers found a better way by setting a single registry value. As a matter of fact, setting HKLM\Security\Policies\Policies\00001001 to 1 will enable all RAPI activities on the device.
Setting this registry key corresponds to the following provisioning script:
<wap-provisioningdoc>
<characteristic type="SecurityPolicy">
<parm name="4097" value="1">
</characteristic>
</wap-provisioningdoc>
Read all about this at its original source.
Setting this registry key corresponds to the following provisioning script:
<wap-provisioningdoc>
<characteristic type="SecurityPolicy">
<parm name="4097" value="1">
</characteristic>
</wap-provisioningdoc>
Read all about this at its original source.
Thursday, November 10, 2005
TechDays and RAPI speed
TechDays in Lisbon finished today and it was a blast! I had the opportunity to deliver two presentations (SQL Mobile and .NET CF Performance) and the place was always crowded, but not my presentations, alas. There were several parallel tracks and it was not uncommon to have participants standing in aisles or sitting on the floor... Congratulations Microsoft Portugal!
In one of the recesses, I was approached by one of my customers complaining about DesktopSqlCe performance when inserting data in bulk. After comparing the insertion performance of Data Port Wizard, DekstopSqlCe was an order of magnitude slower...
My customer's code also needed to be optimized, but that was not the root of the problem. It was in my code. How could that be if both products share most of the base code? On one hand DPW was blasting 11,000 rows in less than 30 seconds over RAPI, while DesktopSqlCe was performing in the tens of minutes range. But wait, I thought, I've seen this before.
When DPW was being developed, I soon realized that synchronous messaging was very slow over RAPI. If after inserting a row in a table (even if the cursor remains open) and you wait for the device to send an acknowledgement message, then you are going to be very slow. So slow as to justify the tens of minutes scenario.
To solve this, DPW uses an asynchronous method of communicating and that is why it does not stop when it finds an error - all errors are reported at the end and are collected asynchronously. This is fast, very fast indeed.
When I wrote DesktopSqlCe I wrongly assumed that my customers would make occasional and rare direct table inserts and updates, so inserts and updates were being delivered in a synchronous fashion, i.e. waiting for a confirmation after insertion or update. This situation is now solved by adding a new attribute to the SqlCeRowset class (similar to the CF 2.0 new SqlCeResultSet class): ReportError. This attribute is of type SqlCeReportError and has two values: Sync (default) and Async. Now you know why.
In one of the recesses, I was approached by one of my customers complaining about DesktopSqlCe performance when inserting data in bulk. After comparing the insertion performance of Data Port Wizard, DekstopSqlCe was an order of magnitude slower...
My customer's code also needed to be optimized, but that was not the root of the problem. It was in my code. How could that be if both products share most of the base code? On one hand DPW was blasting 11,000 rows in less than 30 seconds over RAPI, while DesktopSqlCe was performing in the tens of minutes range. But wait, I thought, I've seen this before.
When DPW was being developed, I soon realized that synchronous messaging was very slow over RAPI. If after inserting a row in a table (even if the cursor remains open) and you wait for the device to send an acknowledgement message, then you are going to be very slow. So slow as to justify the tens of minutes scenario.
To solve this, DPW uses an asynchronous method of communicating and that is why it does not stop when it finds an error - all errors are reported at the end and are collected asynchronously. This is fast, very fast indeed.
When I wrote DesktopSqlCe I wrongly assumed that my customers would make occasional and rare direct table inserts and updates, so inserts and updates were being delivered in a synchronous fashion, i.e. waiting for a confirmation after insertion or update. This situation is now solved by adding a new attribute to the SqlCeRowset class (similar to the CF 2.0 new SqlCeResultSet class): ReportError. This attribute is of type SqlCeReportError and has two values: Sync (default) and Async. Now you know why.
Subscribe to:
Posts (Atom)
