SQL and Shared Variable Comunication Failure when running an .exe application

[BRLUIZFELIPPE]

Hi NI Engineers,

I am struggling with a problem. I have already tried almost everything under my background to solve it, but I just could not get over it.

I have a VI on my PC that access a SQL database via connection string and also some shared variables in a server. Both the shared variables and the SQL database are at the same server. Between this server and my PC there is a firewall and the server is inside a DMZ environment.

On Labview environment design mode, everything works properly. Even when I run the .exe file on this computer, everything runs properly. But, when I built an application and install it on another computer, it just don't work.

I am using Labview 2013.

Can anyone of you assist me with this bug?

Thanks in advance!

[mikeporter]

Right off hand I would look at permissions related to the firewall. Your development machine might have different permissions. Also remember that with an executable it is no longer LV accessing the network, but your application -- which the firewall wouldn't know from Adam...

Can you ping, the remote computer from the machine that can't communicate? Or access it in any way?

Mike...

[BRLUIZFELIPPE]

Hi Mike,

Thanks for your answer.

I asked the domain admin to disable all rules on DMZ firewall to perform an access test. At this situation, I can Ping the server, but the application don't comunicate either. 

For some reason, my PC is always able to access the SQL database and SV, as well.

The difference between my PC and the other PC is that, on the first one there is Labview installed.

Any Suggestion?

[mikeporter]

One of the problems is that both of the mechanisms that you are using are pretty complex processes. To simplify things a bit, on the target machine application create a functional global variable that stores the same data as one of your shared variables. Next, on a remote machine create a small program that uses VI Server to remotely execute that same FGV, but this time in read mode. If the connection works, you should see the data from the target application (by the way, this is the way I often transfer data -- never shared variables, got burned too many times).

Even if it doesn't work (which it likely won't) you'll get an error message that might provide a bit more insight.

Mike...

[BRLUIZFELIPPE]

Thanks Mike,

I will change the code to exchange data via FGV and reply to you soon. Eventhough it doesn`t solve this issue, definetelly it seems to be a better way to develop applications like this.

Thanks,

Luiz

[BRLUIZFELIPPE · Accepted solution]

Hi everybody,

Came back to share with you the solution:

The problem was with the "SQL Native Client". Windows 7 doesn't have it as a default installation, so the application was not able to find the OLE DB provider for ODBC driver. After installing it, the connection was established.

As the server was inside a DMZ, I had to open some specific ports as follows:

udp/1434

tcp//2343,49163

59110-59115

Actually, I didn't experienced problems with the SV. The error was generated when trying to connect to database and sent to the rest of code through the error cluster.

Thanks for the support!

Best regards to everybody.

Luiz