LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way for LV app to communicate with Database/Website?

Hey all...I'm pretty experienced LabVIEW programmer but I'm in somewhat new territory here with communicating with a server/website.

 

We are going to have an online SQL database that stores all data that we record for our application.  That database is going to have a web-based front end that will allow users to add/edit records.

On the other end, we are going to have a LabVIEW application running on a PC that will allow its users to acquire/input data, and also add/edit records for the SQL database as well.  So basically a web-based client and a LV application client, which will most likely differ in functionality.

 

There are going to be multiple PCs running LabVIEW client applications (let's assume upwards of 20 for now).  The idea would be that the user could:

  1. Query the SQL database for an existing entry, and then view/edit that entry or add records to it.
  2. Create an entirely new record. 

I have played around with the database connectivity toolkit and was able to communicate with the SQL databases online, no problem.  But, I'm not sure if that is the best way to do this yet because....

 

Here are our challenges/constraints/specifications:

 

Well we need this to be as low bandwidth intensive as possible as each LV client will be using a GPRS(cell phone) data connection to the internet which is pay per use.  Here are my thoughts on this so far:

  • Having local copies of often accessed records on each machine with incremental updates to the server to minimize bandwidth for queries.
    • Positives/Negatives?
  • Send data to the server in a tagged format (XML maybe?) and then have a server-side application that parses the data and updates it to the database.
    • Postives/Negatives?
  • When updates are made using the website front-end...we would like at a minimum to be able to notify the LV client that an update has been made (like a Push data/notifier service). 
    • How to implement?
    • POP3 e-mail for each LV client might be an option but is there something better?

The data types that we are working with include all standard types (numeric, text, timestamps) and also includes images (jpg) and sound files (mp3) and potentially video in the future.

 

Thanks and I'm looking for any and all feedback.  Let me know if the problem is still fuzzy...I will try to describe in better detail.

 

-Aaron

 

0 Kudos
Message 1 of 8
(3,939 Views)

How often would you need to update the database and/or LabVIEW client?  Would it help if you could do it once per day?  Another thought is to zip a file with the info to be inserted in the database to save bandwidth.  The server would have to unzip and interpret the file...

-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




0 Kudos
Message 2 of 8
(3,937 Views)

MattBradley wrote:

How often would you need to update the database and/or LabVIEW client?  Would it help if you could do it once per day?  Another thought is to zip a file with the info to be inserted in the database to save bandwidth.  The server would have to unzip and interpret the file...


Good question!

 

The data being sent from the LabVIEW client can have different levels of priotirty associated with it.  If it's high priority, it would need to be updated to the database as close to real-time as possible.  Data that is lower priority could all be bundled together in a single file and sent 1x per day/2x per day/1x per week/etc....

 

Message Edited by ajf200 on 02-12-2009 09:59 PM
0 Kudos
Message 3 of 8
(3,932 Views)
Next question: Can the clients (easily) talk to each other -- if they can make a single file for updating the server, that could help, too. In any case, my first thought would be to put the different priority data in different directories. Have another labview (or even a different software package) running in the background, looking for new data (more often in the high priority directories). When it sees something, copy it to the server. When the server confirms the file has arrived, delete the original one. On the server side, it would have to let the client know it received the file and then unzip it/translate it/whatever and insert it into the database. Sound good so far? -Matt
-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




0 Kudos
Message 4 of 8
(3,925 Views)

MattBradley wrote:
Next question: Can the clients (easily) talk to each other -- if they can make a single file for updating the server, that could help, too. In any case, my first thought would be to put the different priority data in different directories. Have another labview (or even a different software package) running in the background, looking for new data (more often in the high priority directories). When it sees something, copy it to the server. When the server confirms the file has arrived, delete the original one. On the server side, it would have to let the client know it received the file and then unzip it/translate it/whatever and insert it into the database. Sound good so far? -Matt

Matt,

 

Sounds good so far.  Interesting idea of putting it in different directories, although I'd like to minimize file I/O as much as possible, especially between different VIs.  I'm also intrigued by using .zip files to cut down on file size.

 

No, the clients won't easily be able to talk to each other.  All messaging between clients will go through the server as well.

 

I guess I'm really looking for how to practically implement this as well.  Like what VIs (protocol) should I be using to get the data to the server?  TCP/UDP/SMTP/FTP/SQL connection/etc...I have little experience making apps communicate with a website/webserver.

 

-Aaron

0 Kudos
Message 5 of 8
(3,922 Views)

Aaron,

 

I was thinking that putting it in a file would help in terms of zipping it to save space.  Then you could read it as a binary file and use the internet toolkit to send it with a TCP write.  Each client would have its own port number.  I think the only things you will need are the TCP open, TCP write, TCP read (for the server), and TCP close.

 

-Matt

-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




0 Kudos
Message 6 of 8
(3,905 Views)

I've been playing around with the "Web Services" examples and it seems like this might be the way to go.  Anybody have any thoughts on this?

 

-Aaron 

0 Kudos
Message 7 of 8
(3,839 Views)

Hi ajf200!

 

I would agree the Web Services is a good option.  Have you seen this Developer Zone article on Web Services: Web Services in LabVIEW ? If you have LabVIEW Full or Professional Development Systems, Web Services is installed with LabVIEW.

 

Kristen H.

0 Kudos
Message 8 of 8
(3,804 Views)