Oracle 11G and dataSocket server conflict

[WaldoUK]

Hi,

Has anybody had conflicts between V4.5 dataSocket server and Oracle 11G?

 

We have a LabView application running on a server which communicates with the data acquisition systems and operator workstations using the dataSocket server. Oracle version 9.2 is also installed on this machine and the operating system is Windows 2000 Advanced Server edition. The application is written in LabView version 6.1 which includes version 4.0 of the dataSocket server.

 

The system ran successfully for many years but we are now in the process of upgrading to version 8.5.1 of LabView which also updates the dataSocket server to 4.5 and upgrading Oracle to version11G.

 

It was at this point that we hit problems as there appears to be a conflict between the dataSocket server and Oracle. We have managed to get the system running by reinstalling LabView v6.1 runtime including the 4.0 dataSocket server then installing the v8.5.1 runtime without dataSocket support.

 

The application now runs happily with v4.0 dataSocket server and Oracle 11G but I would like to be able to identify what actually causes the problem so I can fix it and install the latest version of the dataSocket server. Version 8.6 of LabView has just arrived, is it possible this problem has been fixed in it?

Mike Johnson

BAE Systems

[DanBrowne]

Hi Mike,

What exactly are the details of the 'conflict' you have been seeing? For instance has there been any error codes appear? The more detailed information the better from my point of view.

Regards,

Dan - NIUK

[WaldoUK]

The application is designed as a state engine where the completion of operations in one case determines which case is executed next. The application cycles through a series of cases every second. A general cycle consists of the following; the first case reads an Oracle table and sets indicators to those values, the next case reads the dataSocket for the latest data values from various sources and populates an array, another case then broadcasts the content of that array via the dataSocket to user workstations. This cycle repeats until the application is terminated.

 

Periodically, a case occurs that writes the contents of the array to an Oracle table as an archive. 

 

The data acquisition sources are capable of acquiring data at 50 samples per second for short periods. This data is passed to the application during the cyclic dataSocket read. This data populate a separate array. When all the data sources have been read the data is written to a temporary local file using the datafile VIs until the test completes when the contents of the file are written to an Oracle table.

 

Either of the above two cases can be run separately without problem, but if the archive is enabled while the high speed data is being acquired then the application becomes erratic when the archive case occurs. The application still cycles through the various cases but takes an unusual amount of time in the dataSocket read and broadcast states. Eventually an error 63 or 66 occurs in the dataSocket read case. The application continues in the erratic state until one or the other of the cases are disabled. The application eventually picks it’s self up and returns to normal.

 

As I stated in the original posting If I remove V4.5 of the dataSocket server and install V4.0 the application works as expected with both the above cases enabled.

[Prashant M]

Hi Mike,

I hope you are well.  Thank you for your post.  Your application sounds very interesting.

I have been looking into your issue and the Error 63 received from the server just means that the connection was refused. 

What I am wondering is if you are trying to open the connection each time, or are you keeping the connection open during the entire process?  In either case however, you can programmatically catch the error 63 and try to re-establish the connection and send again.  That way you can verify that all packets of information you send are received.

With regards to the Error 66 that you are seeing, this is described below:Error 66: The network connection was closed by the peer

The network connection might have been closed by someone, or LabVIEW is not configured to allow you to be a client. In the second case, you must configure the VI Server to give you the appropriate permissions by selecting Tools»Options (or Edit»Preferences in LabVIEW 5.x).

I was also wondering whether you have McAfee or a similar software on you system.  You should try and disable the McAfee firewall software.  Even with the internet connection, within McAfee firewall software, set to "allow all", it still does not allow DataSocket to write and read properly.

I would suggest that you also check the connection, server, and authentication, because this error is related to blocks when connecting to server.Please find below some links that I think you will find useful.

Error 66/1148 When Writing to a Shared Variable Using DataSocket

http://digital.ni.com/public.nsf/allkb/29895C80B1015A15862571DC0078747F?OpenDocument 

Why Do I Get Error 66 When Using VI Server to Obtain Front Panel Data from an FP-20xx RT Target?

http://digital.ni.com/public.nsf/allkb/14FFB5B2FDE57B1F86257013004DDA8B?OpenDocument

Why Do I Get Error 66 In My Executable That Uses VI Server?

http://digital.ni.com/public.nsf/allkb/4CF1F88E4A62A20A862571E90005E3C3?OpenDocument 

Common VI Server Errors

http://digital.ni.com/public.nsf/websearch/E1B8CA0B546A803486256A33005AF221?OpenDocument 

I hope that this helps and please feel free to let me know how you get on.

Kind regards,

Prashant M
Applications Engineer
NI UK & Ireland

Message Edited by Prashant M on 09-04-2008 05:10 AM