Today, a similar type of application (“App #2”) is the source of the problem, and the fact that it’s being moved to the same new server made the cause of the problem even more difficult to discern.
Both applications connect to the same Microsoft SQL Server instance. After moving App #1, the problem was connecting to an Oracle Database via ODBC. Connecting to SQL Server worked fine.
However, App #2, while ostensibly identical in its method of connecting to the database, threw an error when trying to connect via the new Citrix server.
This is the same error given if one enters an incorrect username and password, so it’s not the most helpful notification to receive. Also, this application has no error log, and does not send errors to the Windows Event Viewer. App #2 is basically a black box.
I decided to check whether or not XP Compatibility mode would affect how App #2 ran on the new server. Though App #1 was unaffected by this, something had to be different and this should be easy enough to check.
Because the application ran from a network drive rather than locally on the Citrix server, checking the Properties on the executable was not fruitful. The entire Compatibility tab was grayed out.
By copying the application executable to the server, I was then able to set the Compatibility Mode selector for Windows XP SP 3. The application ran perfectly! This did not completely solve my problem though – this app was run by Citrix via batch file rather than an app shortcut.
I figured there must be a way to set the Compatibility Mode within the batch before executing via start.exe.
After digging a bit, I did find several options for doing this. Though the method preferred by many involved adding registry keys, I chose the simplest route.
Adding this line to the batch file just before the call to the application executable solved my problem!