One question that I get a lot is the differences between the open source DBAmp and the supported version DBAmp/Pro. Because the open source version was only forked from the /Pro version 5 weeks ago, there are currently not any large functional differences. The /Pro version does contain some bug fixes, etc.

However, in late December, we will announce our Winter 06 support and that will be in the /Pro version only. At that point the /Pro version will contain major functional differences. A feature I'm particularly excited about is the new Bulk Insert and Bulk Update features that support bulk inserts/updates from an SQL Table to Salesforce.com. These stored procedures are used the same way as the current SF_Replicate proc. All that is needed is a defined Load table that contains the columns of the object and a Id field. For bulk inserts,the stored procs will automatically update the Id in the SQL Load table to reflect the assigned Id by Salesforce.com.

Another new feature in DBAmp/Pro is the ability to connect to the Salesforce.com Offline edition. DBAmp/Pro will connect to the local offline database with full Select/Update/Insert/Delete support. And best of all, any changes you make will automatically be synched to the online version.

Obviously, the /Pro version also includes the email support and access to the forceAmp.com forums. This support is most valuable as organizations are going through their integration deployments.

 Finally, the /Pro version source code is NOT derived from the open source code base but instead is maintained by us internally. There are no open source contributions to the /Pro version. This is important because most companies will not allow the security risk of using an open source version attached to their production SQL Server with access beyond the firewall. We find that while most companies start a trial with the open source version, once they have made a decision to include DBAmp as part of their integration project, they prefer the supported, non-open source version.

So, if you are using the open source version of DBAmp: good and I hope you're seeing benefits from the product. If you've made the decision to use DBAmp as part of your production Salesforce.com integration, great and I encourage you to consider the new features and support you get with DBAmp/Pro.

I've got a great idea for a new Salesforce.com add-on product.  And with the upcoming GA release of AppExchange, I've been trying to figure out how to deploy and sell this product using AppExchange as the marketing vehicle.

The main thing that is stumping me right now is the product design.  The product is primarily a graphing tool of some Salesforce data and uses a C++ graphing library. Sounds like a scontrol to me!

And Dave Carroll's new AJAX toolkit looks like the right way to get the data.  Using the AJAX toolkit and Javascript, you can fetch and display sforce data to your hearts content. But the issue with my product is how to build a scontrol that uses functionality that isn't written in Javascript.  

Many balloons of inspiration have taken off only to be shot down by the details:

Balloon 1: Wrap the C++ library in an ActiveX Control and call it from my Javascript code. The issue is the security problems with ActiveX controls in the browser. First, I would have to digitally sign the control to certify that it is not a threat. Then, potential users of the product would have to modify their browser settings to allow signed ActiveX controls to run.  This seems like a big security hole to open for an add-on product.

Balloon 2: Put the C++ graphing code up on the web as a web service and call the web service from my Javascript code. This has two issues: first, will the customer embrace the idea of shipping some of their Salesforce.com data off in a XML packet to a web service ? And second, the cross domain security issue again because the web service is not in the same domain as the scontrol.

Balloon 3: Port the C++ graphing code to Javascript.  This one is just too much effort and even though the C++ library is open source, it's also around 4,000 lines of C++ and would make a huge Javascript file (and download).

So as of now, I'm not sure the best way to do "cross domain" AppExchange products.  But stick around; this product idea is too good to not figure out the cross domain details!