August 17, 2015 at 10:45 pm
Comments posted to this topic are about the item Connect to Salesforce Data as a Linked Server
August 18, 2015 at 4:04 am
So basically you need to buy the SF ODBC driver to do this, right?
August 18, 2015 at 5:34 am
Yes, which is completely ignored by the author. The website for cdata doesn't even list the price for the product with SQL Server remoting (you have to request a quote), so it can't be cheap.
Subtle content marketing?
August 18, 2015 at 6:40 am
I think this is what Steve was referring to about the gray line between content and marketing.
Standard
Professional
Enterprise / Cloud / OEM
For use with desktop clients like Excel, Access, Word,etc.
$99
(with subscription)
Professional
Enterprise / Cloud / OEM
For use with Web apps, BI, Analytics, ETL, server tools.
$499
(with subscription)
Enterprise / Cloud / OEM
For BI, ETL, Analytics Tool Vendors, Cloud and Linked Server deployments.
Request Quote
412-977-3526 call/text
August 18, 2015 at 6:45 am
So basically the 'article' is an install guide/set up instructions for a very specific driver? We use DBAmp for the same purpose and the provide a nice guide but I won't be publishing it here 🙂
Steve.
August 18, 2015 at 7:28 am
I may be mistaken, but I believe that DBAmp allow you to replicate salesforce data to a local instance of SQL server, correct? Replication/sync is a different problem entirely.
This solution is different - it offers the ability to create a SQL server linked server (https://msdn.microsoft.com/en-us/library/ms188279.aspx?f=255&MSPPError=-2147217396) with live access to salesforce data (no local replication). Basically it makes salesforce data look like SQL (or MySQL), without doing any kind of local copying etc.
August 18, 2015 at 7:44 am
Absolutely it lets you do that. *But* it also works effectively like an OLEDB driver, so you can easily create a linked server (or multiples, one for PROd, sandboxes etc) that is then usable within SQL. To add to that, the folks from DB Amp even give you some added functionality n stored procs and an external executable, basically allowing for use of the SF Bulk API's (which believe me, if you've ever tried to do any type opf update or insert with Salesforce, you want to be using the bulk API's).
So i guess I'm saying yeah, it can be used strictly for replication, but is that all it can do? No, not at all.
Steve.
August 18, 2015 at 7:46 am
As I understand Eric shows how to connect to a standalone Salesforce database server.
Is there a way to create a linked server to "Salesforce as a Service" database at https://login.salesforce.com ?
August 18, 2015 at 8:24 am
Thanks for the information.
August 18, 2015 at 8:29 am
As a customer, DbAmp makes a great product and has great support.
August 19, 2015 at 6:17 am
Hi Steve,
Yes, I know what you mean about the Bulk API - the CData driver uses it internally (and transparently) as well.
One thing that might not be obvious about the article - the linked server feature is common across all of the CData ODBC drivers. So, while this article focuses on Salesforce, the same linked-server capabilities can also be used for NetSuite, DynamicsCRM (on-prem & online), QuickBooks, SharePoint, SugarCRM, etc.
August 19, 2015 at 9:00 am
Does this require the API available from the SalesForce Enterprise edition or is independent of that?
August 19, 2015 at 9:19 am
doesn't require anything local other than the driver (whether that be cdata or dbamp or whoever). these interface with the API, but that's in the cloud.
Steve.
August 23, 2015 at 12:15 pm
Hi,
I thought of doing a POC to test the speed of CDATA ODBC driver from SSIS.
Here is some analysis (please note it is on non-prod environment.)
I used it in SSIS for fetching 8 column from salesforce (Account) table to SQL database.
It took around 8 minutes for inserting 828,000 records in SQL table from SF table.
All columns are string/datetime/bool.
Is it normal speed or am I missing something?
Thanks
August 27, 2015 at 3:01 pm
We use DBAmp, and one of the reasons we chose it was the licensing model. You pay for each SalesForce production instance, not per SQL Server. So we can pay once and access our Salesforce data from as many SQL servers as we like, plus all of the sandboxes (of the same production org). All access by any developer or application goes through a SQL Server linked server, so there's no extra charge per developer or app deployment.
Access to the bulk API is another great feature. We can download a copy of every table nightly without worrying about hitting any transaction count limits.
But to provide connectivity to mobile apps you would have to publish a web service that went through your SQL Servers. If that was your goal you might prefer the CData royalty-free distribution model that would let mobile apps go straight to Salesforce.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply