Remove use of SQL database and save results locally.

[JayWW]

Hello all,

    This is probably too broad of a question to post here with not enough specifics, but I thought it was worth a shot. I'm working on inherited code that's used for final testing products. It's considered proprietary, so I can't upload it.

The issue is we have multiple test stations that save to and read from a SQL database for loading tests and saving test data. We're now making a new standalone test station that won't have access to the database, so I need to modify the code to remove all calls to the database and save all data locally. Since I'm pretty new to Labview, I haven't a clue what to modify or remove without breaking things.

If anyone has some suggestions about how to go about this, it would be greatly appreciated!

Jay

[RavensFan]

You can certainly write stuff out to a file.

We don't know how much data you are writing or how often.

But open up the example finder under Help and look for File I/O.

Basically open a file up at the beginning, continually write new data to the file as you collect it, close the file at the end.

[pincpanter]

No chance to install a database instance locally? It would save development time. It could be a lot of time if things are really complicated.

[aputman]

---

@pincpanter wrote:

No chance to install a database instance locally? It would save development time. It could be a lot of time if things are really complicated.

---

I agree with pincpanter.  What database software are you using?  If you are using MSSQL on a server, you can install an Express edition on the workstation.  Express edition is free to download, as is mySQL.  Copy over any stored procedures, table definitions, etc. and change your connection string to point to the local database.  I do this as a backup system in case the network is down, the assembly lines are still operational.  It does involve syncing the data back to your live database, if that is something that needs to be done. 

[JayWW]

I think so too. I'm now looking into what it will take to setup MySQL on the local machine and access it from there as well. I've never played with SQL before, so this should be interesting. 🤔

Jay

[Mark_Yedinak]

Another approach if you cannot install the DB locally would be to switch your code to using OOP. Granted, this could be a larger undertaking but it would help to make you code more flexible and extendable. You could define an abstract class with the methods for reading and writing the data. Then inherit from that class and create a concrete implementation which use the DB. Another would implement the file based access. If you end up changing databases you could create another instance specific to that database. This will probably be more work up front but could pay off huge in the long run.

[Jacobson-ni]

---

@Mark_Yedinak wrote:

Another approach if you cannot install the DB locally would be to switch your code to using OOP. Granted, this could be a larger undertaking but it would help to make you code more flexible and extendable. You could define an abstract class with the methods for reading and writing the data. Then inherit from that class and create a concrete implementation which use the DB. Another would implement the file based access. If you end up changing databases you could create another instance specific to that database. This will probably be more work up front but could pay off huge in the long run.

---

I think this would be the ideal case but I would probably look to using SQLite instead of regular File I/O as they might be able to reuse a bit more of their existing code (maybe).

[Yamaeda]

The absolutely easiest solution is to install a local DB on the new machine and simply point the program to localhost.

If the server address is somehow hardcoded, it needs to be changed to some ini-file setting, which is should be anyway.

/Y