Anyone use QODBC for Quickbooks?

[Xipooo]

Just curious if anyone has used the ODBC driver for Quickbooks. Was it worth it? Was the licensing good for you? Did you use the OEM, Server, or Single User version?



http://www.qodbc.com/qodbc.htm

[ItsMe]

Currently, third party tools are not in my scope of interest. It may be a time saver but wouldn't know without first hand experience.

Back in the day I used to pinhole to Peachtree using DDE from SDK's provided by Peachtree. I just purchased (another) version of Quickbooks Pro, hoping I will find time to explore what Quickbooks offers directly. I did a little research recently that inspired me to buy quickbooks to see if I can develop an interface, kinda.
http://support.quickbooks.intuit.com...icles/HOW12778

It is not a real time link but could provide fast and free updates to the back office from operations.

The other approach I would like to consider is
http://www.youtube.com/watch?v=1ShTQEn6VgE
Being a partner may be one way to get what you want.

[Xipooo]

Thanks ItsMe. The API is another way to potentially go especially because the online connections are free... but of course that requires our customers to be using Quickbooks Online. Their desktop version API is minimum $1000 per year. Ouch.

We have been using a product from "Big Red Consulting" which does IIF import/export, but that's pretty difficult to work with.

The QODBC driver is an ODBC driver that plugs right into the data file. You can manage the data in the data file just as you would any other ODBC data source with tables/views/stored procedures, etc... That's why I was looking closely at it.

The API might be a good alternative. But if it's a desktop version, I wonder if it's COM compatible or .NET apps only.

[ItsMe]

It is all about what is cost effective. Purchasing DLL files in the past have saved me a lot of time and also leap frogged production. I would suggest investigating what SDK's Quickbooks offers. I will imagine they offer other API's than the one I outlined. Years ago, I gave up on Peachtree when they started requiring you be a partner in order to download their SDK's. Now that I am interested in accounting software again, I want to investigate QuickBooks. Peachtree or Sage50 has left a sour taste in my mouth for various reasons. I do not know if the grass is greener at QuickBooks but, the fact that they offer a format via IIF to import is appealing.

I am going to begin with the IIF and after I wrap my head around that I may look into partnership and SDK's.

I am certainly interested in any info you collect on this subject. This DLL or a similar one offered by a QuickBooks partner (someone who can download SDK's) may be a good solution. Licensing is an overhead and should be calculated while considering the long term. I don't know what the beans say because I have not looked into it yet.

[Xipooo]

I'll have to look more into the SDK. At first it looked rather expensive but now it seems the download is free. The QODBC just seems like a quick way to get to the data, but an SDK might work just as well.

[ItsMe]

It seems as though the QBFC2 COM dll would be the way to go. The XML interface seems like an option that would work (out of the box) with Access. Hopefully, there is not a way to get an entry point to the QBFC2 COM dll using VBA. I looked at it briefly and they have VB.NET example files/project you can download. Could probably find a way to convert to Access.

They also offer a toolkit list from third party vendor's.
https://developer.intuit.com/docs/02...elopment_tools

At least if you first look into it, you will know if you are getting your money's worth using third party solutions. Can't imagine what they have to offer that is not available through the free QBFC2 COM dll and the many sample projects in various programming languages offered by QuickBooks.

I am still going to look at the IIF. My reasoning is that I need to understand what data is easy to update, edit, append. If a specific ledger is updateable through the IIF format, it is probably going to be relatively simple to pinhole into the tables using an API. When you start using API's with complex RDBMS's, you need to understand the necessary constraints to maintain data integrity. I am guessing the IIF files will help me understand the roadmap when I get to the API's.

[ItsMe]

Well, I couldn't help but download the SDK and try out the driver. First impressions are very good. Nice support from Intuit. Lots of sample code and a 500+ page PDF file of documentation as well as an interactive hierarchy of properties and methods.

Sample videos on the site even has an Access VBA example. I listened along and typed the code into my own Access module. My only problem right now is that I do not have Access installed on the machine where my only version of QuickBooks is. I am going to guess that if I want to test what I created so far I will have to publish the Access file as exe.

I tried running the code and I got an exception creating the very first object (don't have QuickBooks on this Access machine). This indicates to me that the DLL file that is a free download is not going to work on a machine that does not have quickbooks installed.

There are a couple other tools in the SDK that I will look at when I feel motivated. Maybe there is a way to get it to work without purchasing and licensing a tool like QODBC. There is an RDS Server and RDS Client that comes with the SDK. I am going to guess this is for connecting a machine that has quickbooks to another machine that has quickbooks and the quickbooks file. I would guess that a true ODBC connection would pinhole into the tables in the quickbooks file.

Too early for me to say what, if anything. Let me know if you have any progress, success, or failures...

[Xipooo]

Well, I couldn't help but download the SDK and try out the driver. First impressions are very good. Nice support from Intuit. Lots of sample code and a 500+ page PDF file of documentation as well as an interactive hierarchy of properties and methods.

Sample videos on the site even has an Access VBA example. I listened along and typed the code into my own Access module. My only problem right now is that I do not have Access installed on the machine where my only version of QuickBooks is. I am going to guess that if I want to test what I created so far I will have to publish the Access file as exe.

I tried running the code and I got an exception creating the very first object (don't have QuickBooks on this Access machine). This indicates to me that the DLL file that is a free download is not going to work on a machine that does not have quickbooks installed.

There are a couple other tools in the SDK that I will look at when I feel motivated. Maybe there is a way to get it to work without purchasing and licensing a tool like QODBC. There is an RDS Server and RDS Client that comes with the SDK. I am going to guess this is for connecting a machine that has quickbooks to another machine that has quickbooks and the quickbooks file. I would guess that a true ODBC connection would pinhole into the tables in the quickbooks file.

Too early for me to say what, if anything. Let me know if you have any progress, success, or failures...

Well unfortunately my attention has been diverted toward other clients needs. This is more of a "when you have time" project. The QODBC driver offers probably the simplest way to connect to the data from anywhere and the least amount of company time to investigate it's use. The SDK is promising and probably the direction I would prefer because I like to be a bit more hands on with the code. I'm a bit more of an OOP guy than most others I work with. That may ultimately be the deciding factor in which way we go. I appreciate your hard work ItsMe. I'm glad you're following up with the SDK. When I get a chance to dig into the documents and code examples myself I'll definitely post my findings. It seems like a bit of an obvious match between Access and QB and I would imagine a good thing to know for your clients/employer.

[victorydata]

Just curious if anyone has used the ODBC driver for Quickbooks. Was it worth it? Was the licensing good for you? Did you use the OEM, Server, or Single User version?

http://www.qodbc.com/qodbc.htm

I use QODBC all the time to develop Access based solutions for customers. It's great because it behaves like a standard ODBC connection. All the QB SDK is accessible and development time is greatly reduced. Definitely worth the money.

[ItsMe]

I use QODBC all the time to develop Access based solutions for customers. It's great because it behaves like a standard ODBC connection. All the QB SDK is accessible and development time is greatly reduced. Definitely worth the money.

I have not had a chance to look into in depth but, what advantage does QODBC have over the SDK's client and host connection drivers? I looked at some forum posts regarding connecting with QODBC and it seems to employ the same drivers that come with the SDK.

[victorydata]

I was only quoting QODBC's claim that all QB SDK is available through their product. I have not worked with the SDK. At first glance, it appears more complicated to implement via code. I like QODBC because it seems to require less effort. Call me lazy, but my time is worth more than $199. With QODBC you can easily view all fields in all tables in QB. Creating SQL commands using query design in Access gets you the data quickly. The query and table definitions can be set up quickly and you'll be on your way to easily pulling, modifying, and adding data to QB.

[ItsMe]

What does $199 entitle you to? Do you need that for each machine that uses the QODBC's DLL files?

[victorydata]

What does $199 entitle you to? Do you need that for each machine that uses the QODBC's DLL files?

Yes, technically it is $199 per machine to read and write data to QB. It creates an ODBC data source under the System DSN tab. However, depending on how you intend to use it, there are ways to reduce costs. For example...you have QODBC installed on one machine and you have the Access app using that installation of QODBC to pull and push data. Share the database so that others can read from it, or set up remote connections to the QODBC machine so anyone can use the shared database app.

[ItsMe]

OK thanks for the info. Very helpful

[byterbit]

QODBC: Used it, liked it, but, as I recall, slow.
The project this was for died some years ago, so my memories are hazy. It was fun to see all that QB data live in Access. Again I recall a sense of slowness doing queries, and it was all on one machine.