Leaderboard

Name: SQLite API Submitter: ShaunR Submitted: 05 Oct 2010 File Updated: 05 Jan 2011 Category: Database & File IO LabVIEW Version: 2009 License Type: Other (included with download) SQLIte API This LAVA Code Repository Download is no longer distributed or supported by LAVA. Please follow this link for further support. Description: This is a Labview API wrapper for the SQLite dll. From the authors of SQLite: "SQLite is a in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private". More information can be found on the SQLite website http://www.sqlite.org. The LabView API contains all the basic SQLite features but it is not a full implementation. However, it is comprehensive enough to satisfy most application requirements for a databse enabled application and the featurelist will grow with each new release. Currently supported features include: Creating, deleting, listing and renaming tables and columns. Selecting, inserting, updating and deleting records. Retrieving SQLite system informaion. "Onlne" database backup. "On Insert", "On Delete" and "On Update" Triggers. File Import. Query Saving. Installation: Unzip to a directory of your choice. Install the pallet menu file (.mnu) provided. Required Packages: Labview (Win x32, x64,) 9.0 or greater. SQLite DLL (Included). Supported Environments. Windows x32, x64 Known Issues. Cannot use semicolons ";" in values when using "Query Transaction" polymorphic instance. Workaround: Replace semicolons with another character (e.g. tilda "~") or use the standard "Query" or "Query By Ref" VIs. Versioning: Current version 1.2.1 New Feature: Added "Conflict Clause" to SQLite_Insert and SQLite_Insert Table.vi (allow replace, fail ect) Performance: Changed "SQLite_Prepare.vi" and "SQLite_Bind.vi" to pass data as a U8 array rather than string. Performance: Changed "Insert" (SQLite_Insert Row.vi) to use "Insert Table". (All inserts now use prepared statements. Performance: Changed some low level VIs to re-entrant for better concurrency. Bug Fix: Changed all polymorphic API VIs to show instance icon. (some context help for VI was not being displayed when set to polymorphic VIs' icon) Bug Fix: Exposed "Distinct" boolean on "SQLite_Select.vi". (No terminal on compane). Bug Fix: Replaced some cursor "Unset Busy" with "Set Busy" in SQLite DB Manager. Bug Fix: Changed "SQLite_Bind.vi" to force sqlite dll to use local copy of data. (Fixes reported bug in LVx32 insering the same data in multiple columns). Changes: Changed icon on "Insert Table" to make more visually discerning from "Insert". Version 1.2.0.0 See changelog.txt. Special Thanks to Gepponline MattW Contact: PM ShaunR on lavag.org (http://www.lavag.org) This LAVA Code Repository Download is no longer distributed or supported by LAVA. Please follow this link for further support.

When processing an array of SubVI references, I always pass each of them through this VI (included in LabVIEW 8.6 and later...prior versions require the VI Analyzer Toolkit to be installed): vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Valid SubVI.vi This VI will return FALSE if the SubVI reference is an Express VI or a "?" missing subVI. It returns TRUE otherwise. -D

Found that old thread! http://lavag.org/topic/4656-memory-allocation/page__p__25647__hl__%22ben%22+inplace+%22array+size%22__fromsearch__1#entry25647 Ben

Hi! i'm porting this toolkit in Ubuntu Linux with version 8.5 of Labview. Some polimorphic vi needs to be modifyied to work correctly such as SQLLite_Delete column.vi and SQLLite_Rename column.vi it said that "you cannot use "SQLLite_Rename column.vi" recursively, so i deleted them After that you place a conditional disabled structure for Unix but to make it work i had to change that condition from OS==Unix to TARGET_Type==Unix. I try changing it in OS==Linux as i see in the conditional Disable Symbols, but it didn't work the first time it said that OS was undefined. now i start labview again and it seems to work...what is better? OS or Target_Type? Instead, TARGET_BITNESS is an unexisting variable.

Others might say you have a life

If you dynamically registered for an event that you had never included in your code, there would be no frame of the event structure that would handle that event. The Event Structure has to have a frame for handling an event of type XYZ. You can change which particular event of type XYZ you're registered for (one coming from VI X or one coming from VI Y or a different user event of the same type) but you have to have a frame to handle whatever that event happens to be. To register for a truly new event, one that isn't in the event structure, you'd need to supply not only an event refnum but also a VI refnum of the VI to be invoked when the event is fired. That VI would need to have 1+M inputs and 1+N outputs, where M is the tunnels on the border of the Event Structure plus one for the cluster of the event data itself (the node on the border of the event structure) and where N is the number of output tunnels from the Event Structure plus one for the output cluster of the event (the dispose? output if it exists... I'm not sure if there's any other event outputs). Thinking about this also made it clear to me why we cannot ever support polymorphism of the user event wires. It is the wires themselves that propagate the types to the Event Structure. Those types have to be known at *compile* time. If you upcast all the wires, it would be no different than if you had created all your events with LabVIEW Object in the first place: you'd loose all the type safety in the Event Structure, and all the events would be named the same. Now, consider this: What's the solution? (When reading this picture, pretend that Graphics.lvclass is named something like "Event.lvclass" and "Point.lvclass" is a derived class of "My Specific Event.lvclass"... doing that pretending will make it easier, I suspect, to get the idea.)