Leaderboard

Oh dear, that was amateurish. This is an unfinished VI that I obviously never tested. Sorry about that. I’ve only been using WITHOUT ROWID tables recently, and in the past I’ve only generated the rowID in LabVIEW and thus never used this dll call. Added later> fixed 1.6.3 version now in the LAVA-CR (note, LAVA will often have a later version than on the LabVIEW Tools Network)

This might be way more than you are looking for in terms of functionality, but I am using a full cloud based Test Data Management system called http://www.skywats.com/. It is a cloud base Test Results Database with Yield & Trent Analysis, UUT reports, Root Cause analysis and much much more. They provide a number of different ways of getting test results into the system, TestStand integration, LabVIEW Toolkit and also free trail.

@drjdpowell: I installed the latest version of your library (1.6.2). There is a new VI called "SQLite Database Path" which is missing the output terminal for "Last INSERT RowID":

This thread is not a question, I just wanted to share the experienced I gained today by troubleshooting our application: Symptom: Engine A encounters an error (expected, so no problem so far) and display it to the user. Engine B, which is totally unrelated to engine A, freezes, and only comes back to like after the user acknowledges the error message from engine A. Consequence: The software engineer (aka me) is pulling his hair and yelling "what the h*** is going on in here?" Then he does some diligent troubleshooting and finds the culprit. Explanation: Engine A calls the "Simple Error Handler" VI, which itself calls the "General Error Handler" VI. This VI analyzes the error and opens a pop-up when there is an error to display. Engine B calls a subvi which calls a subvi...........which calls a subvi which calls "General Error Handler". This subvi doesn't have any error, but still calls "General Error Handler" because it knows that if there is no error, "General Error Handler" will simply return without doing anything. Problem: "General Error Handler" is not reentrant, meaning while it's busy waiting for the pop-up it called to be closed, it can't be used by the sub-sub...subvi of engine B. Therefore engine B is in a frozen state. Conclusion: Those error handlers are a great quick tool for creating super basic application, but not appropriate at all for large, professional applications. I'm pretty sure some of you will think "Well duh, we've been knowing that since LabVIEW 1.0!".