I perform tech support and some development on a number of programs that uses the QuickBooks SDK to perform a variety of functions. Lately I have been noticing that when the user does the following:
Pre-Requisites: - QuickBooks is NOT open on the desktop and is not currently running. - My desktop program is NOT set up in the QuickBooks integrated application list to log in automatically.
1) Opens one of my programs.
2) Performs an action that starts a connection and a session with QuickBooks.
3) The QuickBooks interface returns an error saying you must have QuickBooks open and signed into the company file to perform this action.
4) My program closes the session and the connection and then presents the user with some dialog giving them troubleshooting tips.
Result:
QuickBooks itself continues to run in the background afterwords as QBW32.exe, even though the session and the connection were both closed.
If the user then tries to open up the QuickBooks desktop program, they get an error telling them that QuickBooks is already running. They then have to open up the task manager in windows and close the running QBW32.exe before they can successfully open up QuickBooks.
I have reproduced this this using a very basic C# program that I have written below.
In the test app, I am using the following steps/scenario:
Prerequisite: 1) The test application is NOT set to log in automatically to QuickBooks. It is set to log in only when the user has QuickBooks desktop program open and they have an open company file.
2) Ensure QuickBooks is NOT open prior to the test below.
Steps:
1) Open the test C# application
2) Push the button that says "Open Connection." A connection should be opened up with QuickBooks' interface via the QBXML interop.
3) Push the button that says "Start Session". A session should be started with QuickBooks.
4) Assuming the test pre-requesities are fulfilled up above, you should receive an error message returned from QuickBooks telling you the application is NOT set up to log in automatically and you will need to open up QuickBooks before you can attempt a session.
5) The QBW32.exe should now be running in the background.
6) Press the button that says end session. This should end the session using the QuickBooks interface. The session should already be ended via the try-catch in step 3's button, regardless.
7) Press the button that says "Close Connection". This should close all connections with QuickBooks.
8) The QBW32.exe is still running in the background, even though the session and connection have both been ended and closed.
9) Close the test application using the exit button.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Xml;
using Interop.QBXMLRP2;
namespace Open_Connection
{
public partial class Form1 : Form
{
bool sessionBegun = false;
bool connectionOpen = false;
RequestProcessor2 rp = null;
string ticket;
public Form1()
{
InitializeComponent();
}
private void End_Click(object sender, EventArgs e)
{
Environment.Exit(0);
}
private void OpenConn_Click(object sender, EventArgs e)
{
try
{ //Start a new connection with QuickBooks
rp = new RequestProcessor2();
rp.OpenConnection2("", "Open Connection", QBXMLRPConnectionType.localQBD);
connectionOpen = true;
}
catch (Exception connectionException)
{ //If the connection fails, close the connection to avoid the program from getting stuck in an interop error loop.
MessageBox.Show(connectionException.Message, "Error");
if (connectionOpen)
{
rp.CloseConnection();
}
}
}
private void StartSess_Click(object sender, EventArgs e)
{
try
{ //Start a new session with QuickBooks using the company file specified below.
string ticket = rp.BeginSession(@"C:\Users\username\Documents\Quickbooks Company Files\example.QBW", QBFileMode.qbFileOpenDoNotCare);
sessionBegun = true;
}
catch (Exception sessException)
{
//If the session fails (I.E. QuickBooks is not open with a user logged into the company file and the program is not given permission to
//automatically log in, imeedietly end the session and close the connection.
MessageBox.Show(sessException.Message, "Error");
if (sessionBegun)
{
rp.EndSession(ticket);
}
if (connectionOpen)
{
rp.CloseConnection();
}
}
}
private void EndSess_Click(object sender, EventArgs e)
{
try
{ //End the session
rp.EndSession(ticket);
sessionBegun = false;
}
catch (Exception ex)
{ //If a session was not started already, set the session begun flag to false to avoid getting stuck in a loop.
sessionBegun = false;
}
}
private void CloseConn_Click(object sender, EventArgs e)
{
try
{ //Close the connection to QuickBooks
rp.CloseConnection();
connectionOpen = false;
}
catch (Exception ex)
{ //If the connection was not open, set the connection open flag ot false to avoid getting stuck in a loop.
connectionOpen = false;
}
}
}
}
Based on the example program I have up above, is there any thing that I could be doing to have the QBW32.exe close by itself so it does not stay running in the background under the scenario I described up above?
Update: Myself and numerous other users already have tried turning off the setting "Keep Quickbooks Running for faster startup" in the preferences section of QuickBooks. This does not prevent the QBW32.exe from staying open in the background after the session and connection are both ended. I am seeing this behavior occur with QB 2013 thru 2015.
I can tell you from years of experience of using the desktop SDK from C# that you're not alone. Intuit is aware of it, and it has nothing to do with the "keep running" option. I've chatted with Intuit support staff; some believe it's a bug and some believe it's by design.
I've got a WinForms app that has been in production since QuickBooks 2006, and starting around 2011 (Enterprise 11), this problem of the process hanging around started. As of 2013, even the SDK's tester app ("SDK Test Plus 3") would do the same behavior as your tester app.
My app is run on many PC's at my client, however the part that communicates with QB would call to the instance of QB on their server (not QB installed on their PC's), and I chose to use the "Kill QBW32 if it won't close" idea. In 2014 I changed it to communicate with QB on their desktop (since they have QB on their PC) and NOT use the kill technique (because they may be running QB at the same time). Because of this change, I haven't had to worry about QBW32 still running and I haven't had any problems (my client is the type to let me know).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With