LabVIEW and Web Service, ActiveX, and .NET dll

[JoMo]

We are starting a new project and we need to choose between three technologies for connecting to a SQL Database via LabVIEW.

The options are:

 1. WEB Service

 2. ActiveX dll  

 3. .NET dll

Projects are to be compiled on LabVIEW development stations, and installed on remote work stations ('.exe' files).

There are some questions about these options, which consider:

 1. Dll's has to be installed on Server or locally?

 2. If Dll is on server, could different users use it simultaneously with no collisions?

 3. Could a WEB Service be rollbacked to a previews version? (like using a Source Control)

 4. What are the pro and cons for these technologies, considering change making (add/remove/change inner methods) and updating the work stations.

   a. When there is a need to re-install?

   b. When there is a need to re-start?

   c. When there is a need to re-compile?

Thanks,

Joseph

[MarcoMauri]

Hi!

Why don't you use labview database connectivity toolkit?

Marco

[JoMo]

---

@MarcoMauri wrote:

Hi!

Why don't you use labview database connectivity toolkit?

Marco

---

We have been using it, but now we decided to use an interface instead, so we wouldn't have a direct access to the database anymore, only services.

[Michael.Proctor]

I am not too sure what you mean by a WEB Service,

however what I have used fo rthe last tne years

is from LabVIEW a TCP connection using http protocols to a

web server running on either a remote or local server.

The web server then runs the requested CGI script ( ie the request sent from the LabVIEW app )

to process all my DB requests.

The advantage of this is that for some request I can do a large amount of pre or post processing

or reconfigure the data before it is sent to the DB.

THe BIG advantage is that I can change, optimise or debug the CGI scripts and SQL independant of the LabVIEW apps

that can be running on many differetn systems so not easy to keep upto date and allows a good degree of data abtraction.

I actually just have one CGI and its sub-files written in PERL

the different requested tasks are past to the public CGI and then redistributed to the functions that handle those requested task.

The BIG downside is that apache can typically only handle 4000-6000 characters per request so I had to write a my communication protocol to chop up big data uploads.

I do not always have a permant connection to the web server as each labvIEW can run multiple parrallel request so there is a littel bit of 

time overhead per request as the perl scripts parse and load but these days with the faster networks and CPU this is not much of a problem.

michael

[MarcoMauri]

The advantage of this is that for some request I can do a large amount of pre or post processing

or reconfigure the data before it is sent to the DB.

THe BIG advantage is that I can change, optimise or debug the CGI scripts and SQL independant of the LabVIEW apps

that can be running on many differetn systems so not easy to keep upto date and allows a good degree of data abtraction.

michael

---

Hi Michael,

I'm trying achieving the same goal using stored procedures.

This is less flexible than your PERL scripting but doen't introduce any other component / layer that must be mantained.

Regards,

Marco

[Michael.Proctor]

Stored procedures do work, however PERL or other server side scritping is so much more powerful.

The way I have written them I can also intiate some porcess or retreive data etc using a secure browser

connection in a much more write once, use anywhere.

There is a small amount of work to set up an Apache server - but you only need to do it once and all LabVIEW clients can access

that server remotely has a big adavantage.

I did have to program in a server request que so that if there is a network interruption the 

requests to the DB will be serviced once the network connection is re-established.

michae