I see a lot of FAQ about installing QODBC for multiple users, but it remains unclear to me exactly how this product is installed and runs with QuickBooks Enterprise 8 in a real client/server environment where the QuickBooks data and the QuickBooks Database Server Manager reside and run on the server, and QuickBooks Clients run ONLY on workstations.

Will QODBC run on a Windows 2003 Server where no QuickBooks client runs on the server? In this case I am not trying to deploy QODBC for end users, but as a way for a nightly, server-based task to synchronize some data between QuickBooks and another database.

If QODBC requires the QuickBooks client, then how do you go about configuring such a server-based nightly task? Do you have to leave a user logged into Windows and/or an instance of the QuickBooks client running? Hopefully not! But if so, can that be reliably automated?

Can I run a Windows application, that has been set up with QODBC/QuickBooks integration privileges, as a scheduled Task under an admin user? Thus avoiding having to leave an administrative account  literally signed in perpetually? You can generally run applications as a scheduled Task without leaving a user signed in.

Do I really need the QODBC Server edition if I am only accessing QuickBooks data via an ODBC DSN from an application on that same server? In other words, is the QODBC Server edition really providing any needed or additional functionality if you don't check to enable DCOM and/or Remote Access? In any case, would it be better to set up my application on a dedicated workstation running the QODBC Desktop edition? Thus also avoiding having to install the QB client application on the server? .... I want to buy the QODBC Server edition if that is what I need, but I also want to make sure that I understand the product and set this up the most practical and reliable way.

The best way is to simply just try what you want to do first. See: How does the 30 day evaluation work? How can I evaluate the Desktop Edition? The QODBC Server Edition is only required when QODBC is called by a Windows Service (like IIS, MS SQL Server) or through a Windows Service like the Windows Scheduler as a Scheduled Task. It has nothing to do with a server. Some developers even need to use the QODBC Server Edition on their Windows XP notebooks because they are building ASP.NET applications. 

See also: How do I setup QODBC to auto-login into QuickBooks and start it if it's not running? 

So when you say that the Server Edition is only required when QODBC is called by a Windows Service, I think that implies that DCOM or Remote Access would have been enabled in the QODBC setup? So I think I can get by with just the Desktop Edition for now.

I have installed the QODBC driver and experimented right much on a workstation. We have only one server, and it is our production server, so any advice I can get before I go "messing that up" will be most valuable

Thanks for the example!

I plan to write an application that will start on a schedule, talk to an ODBC driver, and finish sequentially .... vs. a service or application that would be called on for ad-hoc and possibly simultaneous requests (i.e. "QODBC and Windows Service" case study), so I think I don't need the Server Edition at this time.

The QODBC ordering page does actually call the Server Edition the Web Server Edition, which probably does more accurately imply when you need it vs. the Desktop Edition.

It actually has nothing to do with Sun's ODBC driver or QODBC. This has to do with QuickBooks and Intuit's qbXML SDK that requires the use of the QODBC DCOM Servers to bridge between your service and QuickBooks which can only run as either a foreground or background "desktop" application.

See also: Can I use your QODBC Driver with the Java ODBC Bridge product from Sun? 

Thanks for the Java ODBC Bridge example.

It sounds like I may need to find and use a DCOM bridge instead of the Java ODBC Bridge.

Okay, that is good news! I would much rather write to the java ODBC Driver than try to instantiate DCOM object proxies in Java!

So to help me continue to improve my understanding...... When you check "use DCOM Server" in the QODBC is that telling QODBC to talk to QuickBooks via a DCOM interface instead of directly to the SDK? I was originally thinking that option was telling QODBC to enable its own DCOM interface.