Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/27/2012 in all areas

  1. Hello, I’ve been working with SQLite for a logging application and I thought I might offer my SQLite LabVIEW wrapper for possible inclusion in OpenG. There are at least two other implementations out there, both with licensing restrictions, but it would be nice to have this in OpenG as I think SQLite is a major addition to the capabilities of LabVIEW. Below is a zip file; it includes a couple of examples. SQLite LabVIEW.zip LabVIEW 2011. SQLite dll for Windows (32-bit) included. NOTE: more recent version now in the Code Repository. An (incomplete) menu: Here is the block diagram of Example2: There are basically two use modes: (1) calling “Execute SQL” on a Connection to run SQL scripts (and optionally return 2D arrays of strings or variants from an SQL statement that returns results); and (2) “Preparing" a single SQL statement and executing it step-by-step explicitly. The advantage of the later is the ability to “Bind” parameters to the statement, and get the column data back in the desired datatype. The “Bind” and “Get Column” VIs are set as properties of the “SQL Statement” object, for convenience in working with large numbers of them. This package closely follows the SQLite C/C++ interface and is intended to facilitate the execution of SQL scripts, rather than provide VIs that substitute for SQL statements. Thus there are no VIs for creating tables, triggers, etc. The SQLite website provides extensive documentation of SQL and the C/C++ interface. The only differences from the C/C++ interface are: 1) “Reset” and “Finalize” do not return the error code from the previous “Step” (as this would be both unnecessary an confusing in LabVIEW) 2) The default busy timeout for waiting for a database file that is temporarily “busy” due to another connection is set at 5000 ms, rather than 0 ms. 3) I created a “First Step” VI that wraps “Step”, intended to be the first call on Step that actually execute the statement (further calls to Step increment through return result rows). I did this to allow future potential retry logic in “First Step”, and to have a clearer set of VI icons showing the difference between executing a statement and stepping through result rows. As I said, it would be really nice to have an SQLite interface in OpenG. I’ve only just scratched the surface of what can be done with SQLite (see, for example, the “Full Text Search” and “R*tree” extensions). — James
    2 points
  2. A friend pointed me to a website dedicated to restoring rare words to common usage. The site randomly picks a word for each visitor to popularize. I got two, and both of them are excellent choices for me since I have a use for both of them. The one that I encourage LabVIEW users to adopt is: primifluous: that which flows first. As in: "The primifluous wines were excellent." For LabVIEW and dataflow, the usage is obvious: "The primifluous nodes initialize the hardware." "Perhaps you should make that assertion primifluous.""FP Terminals are primifluous unless placed inside a structure node." (The other word, in case you're interested, is "nidifice", and older term for an eagle's nest. Pronounced with "nigh" at the beginning and rhymes with "edifice". Given that NI's mascot is Nigel the Eagle, and that this term begins with "ni", I will henceforth refer to NI headquarters building as The Nidifice.)
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.