Jump to content
News about the LabVIEW Wiki! Read more... ×

Recommended Posts

17 hours ago, Stobber said:

djpowell, could you add support for extended error codes to this API? I'm struggling with a SQLITE_CANTOPEN error on a cRIO that never used to appear, and I don't have enough context to know what the heck is wrong.

Also, could you modify SQLite.lvlib:Format Error.vi to yield the full call chain? Figuring out where an error came from without it is sometimes really hard. If you don't want to stringify the call chain all the time, maybe make it an option I can toggle on Open?

I will do both those things.  

  • Like 1

Share this post


Link to post
Share on other sites
On December 16, 2016 at 6:45 PM, Stobber said:

djpowell, could you add support for extended error codes to this API? I'm struggling with a SQLITE_CANTOPEN error on a cRIO that never used to appear, and I don't have enough context to know what the heck is wrong.

Also, could you modify SQLite.lvlib:Format Error.vi to yield the full call chain? Figuring out where an error came from without it is sometimes really hard. If you don't want to stringify the call chain all the time, maybe make it an option I can toggle on Open?

See the 1.6.5 version now in the CR.   I added the extended code in the Error Description, after the standard error description.   So SQLITE_CANTOPEN(nnn), with nnn the full code, which you can lookup at http://www.sqlite.org/rescode.html.  At some point, I’ll implement the Extended Error names, but I don’t have time now.

  • Like 1

Share this post


Link to post
Share on other sites

Note, the latest version, 1.7.2 just posted, includes a “Load Extended Math Functions” method, which loads an SQLite extension dll that adds a large set of math functions to the very limited set in standard SQLite.  The functions are:

Math: acos, asin, atan, atn2, atan2, acosh, asinh, atanh, difference,
degrees, radians, cos, sin, tan, cot, cosh, sinh, tanh, coth, exp,
log, log10, power, sign, sqrt, square, ceil, floor, pi.

String: replicate, charindex, leftstr, rightstr, ltrim, rtrim, trim,
replace, reverse, proper, padl, padr, padc, strfilter.

Aggregate: stdev, variance, mode, median, lower_quartile,
upper_quartile.

Tested on Windows with LabVIEW 32-bit.  Should work with 64-bit as I include the dll compiled with both witnesses, but I have not tested.  See the provided example.

  • Like 1

Share this post


Link to post
Share on other sites

Hello!

In my project I created couple of tables with foreign keys. I enabled them using "PRAGMA foreign_keys = ON;".
Foreign key constraints work when I try to add a row containing non-existent parent element, such query simply gets
ignored without reporting an error. It makes it difficult to debug which query failed and why.

After doing some research on why it happens, I found that foreign key constraint errors are part of "Extended Result Codes",
(don't confuse with "Extended Error Codes"). By default "Extended Result Codes" are disabled as written here:
Enable Or Disable Extended Result Codes

In order to enable extended result codes the following function has to be called on the database handle:
int sqlite3_extended_result_codes(sqlite3*, int onoff);

Unfortunately I couldn't find an accessor method to get the database handle, so I had to modify your class and add additional
method to it which enables the "Extended Result Codes". It is not the best solution and makes it difficult to share the code
between machines. 

Is there a way to enable extended result codes without modifying the SQLite library source?

SQLite is a great library, thank you James for it!

Max

  • Like 1

Share this post


Link to post
Share on other sites

Hi Max,

The actual bug, I think, was that “Step.vi” was ignoring errors outside of 1..99.  It has a case structure that only passes those codes to the error-handling subVI (written, originally, because 100 and 101 are not errors).  I have changed it so that the extended error codes are now passed (see version 1.7.3 just added to the LAVA CR).  I tested it by making a foreign key error and it now works.

Bugfix SQLite.png

  • Like 2

Share this post


Link to post
Share on other sites
On 30.4.2017 at 4:01 PM, drjdpowell said:

Hi Max,

The actual bug, I think, was that “Step.vi” was ignoring errors outside of 1..99.  It has a case structure that only passes those codes to the error-handling subVI (written, originally, because 100 and 101 are not errors).  I have changed it so that the extended error codes are now passed (see version 1.7.3 just added to the LAVA CR).  I tested it by making a foreign key error and it now works.

 

This also solved my problem while inserting an existing/equal record and waiting for an 'UNIQUE constraint failed'. Now it's in the error chain. Thanks a lot for this !.

Jörn

Edited by joernheit

Share this post


Link to post
Share on other sites

The read-only option seems to be doing the right thing from what I've tried so far.

Thanks

---------------------------------------------------------------------------------------------------------------

 noi that o to dep |  phu kien do choi xe hoi  |   noi that o to ha noi 
 
 
Edited by Jan_bee
edit content

Share this post


Link to post
Share on other sites

I have problems with the Cyrillic alphabet.
The database successfully works with the text, but I can not create the database file in the folder with the name containing the Cyrillic.
The sqlite open function produces an error

Error 402873 ...
SQLITE_CANTOPEN (14): unable to open database: C:\data\...\PґР°С,Р°\sys_bd.db
where "
дата" is a distorted folder name in Cyrillic.

Share this post


Link to post
Share on other sites

Can you attach an example VI that shows the problem?   I can then debug the issue.

Share this post


Link to post
Share on other sites

It seems that the problem occurs if the folder does not exist. If the folder already exists, the connection to the database is successful.

Share this post


Link to post
Share on other sites

Any objections to moving SQLite LabVIEW up to LabVIEW 2013 (from the current 2011)?

Share this post


Link to post
Share on other sites

Sounds reasonable.  Even NI only supports four versions for some of its modules (e.g. Vision Development Module), so I've finally jumped from 2012 to 2017.  Is there a way to keep the current install available in VIPM if using LabVIEW <2013?

Share this post


Link to post
Share on other sites

VIPM keeps a cache of all versions, of all packages installed, locally.  So if you've ever installed the package, and then installed a new one, then from VIPM you should be able to right click the package and choose to install a different one.  In 2017 both will show up as able to be installed, and in 2013 only the one compatible one will show up.

Share this post


Link to post
Share on other sites

Forgive my ignorance here, as databases are currently way over my head. My initial reason for viewing this thread was in search of a library whose functions could run on a cRIO-9068 (Linux) controller to write system data snapshot updates to another system (a freebsd box, lets say.) Would this library work on a linux cRIO? The tutorial videos I've watched on the sqlite library look really promising for my application needs. 

Share this post


Link to post
Share on other sites

Hi James,

I've seen you show off some cool demos with the JSON extensions. Is there any instruction on how to include that in this library?

Cheers,

James

Share this post


Link to post
Share on other sites
On 11/28/2015 at 0:47 PM, drjdpowell said:

A beta version of 1.6 is posted here.  If you ignore the newest features, you could use this in production code; it has the latest SQLite 3.9.2, including the interesting JSON1 extension.

^^I think its already compiled in

Try creating a memory database and executing one of the sample queries like "json_array_length('[1,2,3,4]')" which should return 4. If I'm remembering correctly, these queries just worked with the vi package.

Share this post


Link to post
Share on other sites

It is built in.  Just use it.

BTW, Something not built in is the extended math functions (log, sin, stdev, and the like).  But I include a vi for loading that:

Load Math.png

Edited by drjdpowell

Share this post


Link to post
Share on other sites
Quote

Any objections to moving SQLite LabVIEW up to LabVIEW 2013 (from the current 2011)?

late answer....

LabVIEW 2014 will be important to support a long time as it is the version of LabVIEW Home...

Share this post


Link to post
Share on other sites

We have an existing exe out in the field with the appropriate dll folder beside - I guess the version is about two years old. There are several installations.

If now a new package built with a newer wrapper version in LabVIEW will be distributed, but a user replaces only the exe and misses the dll, is there a problem with the existing functionality (nothing new on the database part has been added)? Is it backward compatible or should the SQLite version - which is available and goes hand in hand with the wrapper - be checked?

thanks

Share this post


Link to post
Share on other sites

The dll should be automatically included in any exe; does that not happen with you?  I have not tried using older dlls, but I suspect the would work.

Share this post


Link to post
Share on other sites

Hi,

  i would like to use your library to save images on a field of a table in SQLite.

Is it possible?
How should I do?

thank you so much.

Share this post


Link to post
Share on other sites

The attached code shows how SQLite will interpret various types into an integer. It makes me a little nervous that there's no warnings or other way to determine that a value might not match what was requested. I guess I could check every value for its column type. Is there an easier way that I'm missing?

Test type handling.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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