PARALLEL / REAL-TIME DATABASE UPDATES

[translucent]

I'm a LabVIEW beginner and would like to know what you think about using LabVIEW to make real-time and parallel updates to a SQL Server database. I presently use a serial overnight process to update my SQL Server backend database using stored procedures, MS Access, and VBA. There are a few hundred steps and currently the only way to update the database is to run the update process sequentially from beginning to end for the entire database. Since this takes about 8 hours a day, I can only run it once a day. My initial impression is that LabVIEW might be a nice way to represent the dependencies in the data, but the number of processes might be overwhelming to look at graphically in LabVIEW. Thank you.

[jgcode]

[Queue ShaunR]

[ShaunR]

[Queue ShaunR]

Thanks Priscilla

I'm a LabVIEW beginner and would like to know what you think about using LabVIEW to make real-time and parallel updates to a SQL Server database. I presently use a serial overnight process to update my SQL Server backend database using stored procedures, MS Access, and VBA. There are a few hundred steps and currently the only way to update the database is to run the update process sequentially from beginning to end for the entire database. Since this takes about 8 hours a day, I can only run it once a day. My initial impression is that LabVIEW might be a nice way to represent the dependencies in the data, but the number of processes might be overwhelming to look at graphically in LabVIEW. Thank you.

I'm not really sure what you have in mind here. Maybe your current VBA application is sequential because the operations are indeed sequential (no point re-indexing a table before you delete a load of rows for example).

I think generally speaking though, that any move away from VBA (and definitely away from Access ) will have performance benefits with the caveat that there are not many interfaces to Access that would be more efficient than the interface between VBA and the DB (I assume your using VBA within Access). With databases, just running more threads of the same process doesn't equal better performance (a thread will stall if a table is locked by another thread), but moving away would enable you to optimise your queries and give you greater control over those functions that can be executed simultaneously.

Perhaps a better short-term route might be to look at Visual Basic since you will be able to more easily port existing code (CopyPasta with Hacksauce) whilst being able to assess what functions can be realised asynchronously. In addition, you will be running compiled code rather than interpreted (I think VBA is interpreted at least) and you will be able to see more easily how and where the software is idling; waiting for the database to complete.

Many people just go for a text file with the SQL and squirt the SQL direct using PassThrough to bypass JET. The VBA becomes little more than a file reading function with a for loop and to change the queries you don't have to write any VBA. I have heard of significant performance improvements just by doing that alone. Indeed, you could very easily write something similar in LV (very quickly) and see if you can achieve better performance by doing a side-by-side comparison with a section of the existing VBA code. After all. You don't want to commit to a technology change only to find 2 months later after re-implementing that it's just as bad