When I close my QuickBooks on my machine my Web Connector stops running:
Application requested to abort
I want to keep my web connector running even when QuickBooks is close.
And also I choose the option while loading connector file: "Yes, always", which allows access even if QuickBooks is not running.
Configure a hook to listen for:
QUICKBOOKS_HANDLERS_HOOK_SENDREQUESTXML
The hook will pass you the company file path. Reference
Related
I'm trying to help a client who has a web application (ASP/C#) that integrates with Quickbooks via the QBXML SDK.
I want to open up a connection to an already active QuickBooks instance in a user session.
The relevant code in question:
if (rp == null)
rp = new RequestProcessor2();
if (!connected)
{
rp.OpenConnection2("IMS", "Internal Management System", QBXMLRPConnectionType.localQBD);
connected = true;
}
if (xticket == null)
xticket = rp.BeginSession(cfg.qbfile, QBFileMode.qbFileOpenMultiUser);
As is, this will attempt to launch a new instance of Quickbooks via DCOM, which is not a viable option. Following the QBSDK documention, I attempted to pass null to BeginSession's first argument, which should use the open qbw file.
However, instead of the expected action of connecting to the running instance of Quickbooks, it launches a new instance, eventually yielding the error:
"If the QuickBooks company data file is not open, a call to the "BeginSession" method must include the name of the data file."
The IIS AppPool running the web app uses the same user as the Quickbooks instance I'm trying to connect to.
This was all set up by a third party who is no longer available, and, of course, they left no documentation whatsoever on how this system was supposed to work. Any assistance would be welcome.
I'm trying to help a client who has a web application (ASP/C#) that integrates with Quickbooks via the QBXML SDK.
Unfortunately, this approach will not work.
It's a well-known limitation of QuickBooks that:
QuickBooks has to be running in the user session you're trying to connect from
QuickBooks has to have access to a GUI (it uses a GUI message pump to function)
Because your web app is running in from within IIS, neither of those two criteria are met, and connections to QuickBooks will fail. You should be using the QuickBooks Web Connector instead.
I want to open up a connection to an already active QuickBooks instance in a user session.
Unfortunately, QuickBooks won't allow this.
I managed to create an acceptable workaround to my problem, for anyone trying something similar. (Which, honestly, I don't recommend. I'm working with legacy code here.)
First, a brief overview of my research:
The QBXml interface with QuickBooks uses COM requests in order to communicate. Now, for whatever reason, whether design, bug, or limitation in COM, Quickbooks cannot communicate across LSA Logon Sessions. In practice, this means that the same console session that Quickbooks is running under must also run the QBXml code. Additionally, both Quickbooks and your application must have the same UAC elevation status.
I found no way to get IIS to reliably launch Quickbooks. The individual who setup this system before me managed to do so through some very... unorthodox methods. It was incredibly flaky, and the cause of multiple issues.
Regardless, I did manage an acceptable workaround, in the form of IIS Express. IIS Express can run under a standard user session. As such, running both Quickbooks and the web app (through IIS Express) under the same Logon Session allowed them to communicate successfully.
It is not a permanent solution, as there are drawbacks to running a service such as this in a standard user paradigm, but it is an acceptable workaround, and will allow my client to run their business while we refactor. I plan to first decouple the portions of the app that communicate with Quickbooks, moving them into their own codebase. This will allow the web facing portions of the app to operate in a more standard manner, and communicate with the QB integration code through a more reliable means than COM calls.
Thanks to Keith Palmer for helping point me in the right direction.
I know that many software are updated by a windows service installed together. I made the service to serve as an update helper and a data server for my client application. But I am stuck on how do I control my client application from this service.
First my service will check for updates on the remote server and then download files.
It will broadcast the news to clients which will ask users if they want to update now or the next execution.
On the time to update, the client application can not delete it's own executable file, so, it would make sense if it asks the server to do it while it's not executing, and then when finished deleting and renaming the files, it would re-execute the client.
If the service is in session 0, it could not be able to re-execute the client to the same user session.
The other possible problem is when the very service would need an update. It could be solved by been updated by the client instead of itself.
So, in the case of updating client and server, should I need to create a third application to do the job. if this 3rd application is a console app, it would be no problem to execute it from the service, right?
If there is a solution that doesn't include this 3rd app, it would be the best.
Note:
The service is not just an update service, but a server to inform user access and rights. The main client application will not access the user information database directly.
If the service is in session 0, it could not be able to re-execute the client to the same user session.
Yes, it would, if you use CreateProcessAsUser() to specify the user account and the desktop to run the app on. The client could convey that info to the service before terminating itself.
But in any case, updating an exe requires it to stop running first. So when updating the service, especially since the service does more than just handle client updates, it would be safer to use an installer to stop the service, replace the exe, and restart the service. In which case, why not do the client update using an installer as well? The downloaded update could be a self-contained installer that stops both client and service as needed, replaces the files, and then either has the client or service delete the installer after it exits, or the installer can ask Windows to delete the installer upon the next OS reboot.
I am creating a utility that runs as a service and starts applications. As long as I log in as an admin and start the service it will run the applications. I log out and the service (and applications) continue to run. But, if another user logs in with different credentials they cannot access the front end GUI of the applications started by the service utility.
I was wondering if there is a built in account which I could use that may solve the issue? Or if anyone has any ideas or insight in the matter?
Windows Services can only be set to "interactive" when run in the system account. Notice the placement of the "Allow service to interact with desktop" checkbox on the Log On tab when configuring the service (via the Control Panel Services application).
Beyond that, are the other users logging in via RDP? Run mstsc with the "/admin" flag to ensure that they are going to Session 0 where the service will display its windows.
And finally, beware interactive services! You are probably on Windows XP or 2003 which is why it kind-of works, but Windows Vista, 7 and 2008 behave very differently (search for "Session 0 isolation").
I've build a Windows service that allows a user to choose a DSN and the service will access it and peform tasks on it. The code works without error when running under a test command line application, and fails when running as the actual Windows Service.
My question is, are Windows Services not allowed to access User DSN? Is there any way to still allow users the ability to create and configure DSNs for the service to use?
check What are the access restrictions on accessing a DSN
I have two servers in a domain. Web Server & Database Server.
I have a number of standard .net websites accessing the SQL Server with no problems, using SQL Username/password combos for each database.
Sharepoint configures the access as Integrated Security=True
When I ran the Config wizard, I 'briefly' saw the Admin top-site.
After a short browse around, I lost the connection. [I touched/changed nothing!!!!]
I now get "Cannot connect to the configuration database."
It seems obvious that the problem is one of access permissions to the database but I can't see it.
The IIS Website uses the Sharepoint AppPool which in turn uses a Domain Account that successfully created the SharePoint_Config Database and & Content databases. They obviously continue to use that account.
The Event Viewer shows multiple instances of:
"Unable to connect to the database SharePoint_Config on [Database Computer]. Check the database connection information and make sure that the database server is running.."
Any suggestions?
This occurs when:
The SQL database or service is not online/running.
Internet Information Services (IIS) is configured to run in IIS 5.0 isolation mode.
The account that is used by application pool does not have the required permissions to the SQL Server database.
Network connectivity has been lost between the Windows SharePoint Services server and the Microsoft SQL Server server.
Check all of those and if all of that is set, check your sql server. Make sure your config database isnt marked as 'suspect' or that something else isnt off. Try resetting your SQL service.
I've also had this happen when an application pool account was changed. Even if the application pool is online, sometimes recycling it does the trick. Alternatively, confirm the application pool account:
Open Server Manager.
Click on Roles.
Choose Web Server (IIS)
Choole IIS.
Open server in the Connections panel.
Choose Application Pools.
For every item in Application Pools, click on it once, and then choose Advanced Settings.
Under Process Model, Identity,
change it, choose "Custom Account".
Enter an account and password for an account with a lot of permissions. I used the Sysadmin.
Restart the Web Server.
Also, 32 or 64 bit? Make sure IIS is running in the right mode, sometimes additional software installs can change things:
First, fix IIS:
\inetpub\AdminScripts\cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 False
Second, reregister the .Net isapi filters:
\windows\microsoft.net\Framework64\v2.0.50727\aspnet_reg
iis.exe -i
If it is none of the above, have there been any DNS or NETBIOS changes? That is also a common cause.
If nothing else works, simply try to reboot your server.