-
Posts
699 -
Joined
-
Last visited
-
Days Won
76
Community Answers
-
LogMAN's post in SQlite update time was marked as the answer
Way better
Still you perform many write operations by executing the SQL in a loop without a transaction. The more values you have, the slower your loop becomes. Your current implementation might result in incomplete data in case of SQL errors (you can't undo your actions)! Try to add a transaction around your loop (It's very easy to do, costs nothing and is at least worth a try):
Transactions will prevent file-writes for as long as they are not committed (this is why it might save you some more time). By calling the Commit VI at the end, all data will be written in one go. In case of errors you can just reverse everything by doing a rollback (The Commit VI will do a rollback on error automatically).
-
LogMAN's post in Destruct object from an Array after Cleanup was marked as the answer
The way your VI is implemented is the correct way to dispose of objects (or any given non-reference type in LabVIEW).
The wire has "loose" ends (after the last VI), so that particular copy of the object is removed from memory automatically.
Only reference-types must be closed explicitly (like the DVR). So your final VI just has to take care of references within that object to prevent reference leaks.
-
LogMAN's post in List all Fonts was marked as the answer
If you don't mind .NET try this:
Not sure if there is a build-in solution for that.
-
LogMAN's post in Remove block diagrams for source-only VIs in Source Distributions was marked as the answer
Okay, I finally found a solution:
A second project had no issues, even though it is basically a copy with a few alterations. After a stroke of genius clearing the compiled object cache for the application builder solved the problem. Now everything is fine again.
I hope this helps anyone who stumbles over the same issue.
-
LogMAN's post in Using SolidWorks API was marked as the answer
ISldWorks is an interface that does not actually implement any code and therefore has no functionality. You would have to implement that interface yourself in order to provide any functionality. Since that is the case, an implementation in LabVIEW is impossible (you cannot implement .NET interfaces in LabVIEW)
This is an example in VB where you create an instance from SldWorks.Application which is an ActiveX object!
In order to create an ActiveX instance use the function from following palette: Connectivity >> ActiveX >> Automation Open
Create a constant as input and choose 'Select ActiveX Object'. You'll get a list of available ActiveX-Objects (this of course requires you to actually have them installed)
You should definately look into that, but this has absolutely nothing to do with your .NET assemblies!
Your basic approach is okay, but whenever you want to use an object, you have to create an instance of it (or have a function return it). You only provided a constant that defines the type and no instance. This is very difficult for me to describe, so here is an example:
Try this out, it works
EDIT: Before I forget, I found a link to a document which describes some detailes to the interface mentioned ealier: http://sw.fcsuper.com/index.php?name=UpDownload&req=getit&lid=157
-
LogMAN's post in Where to find the latest runtime engine was marked as the answer
I use the FTP: ftp://ftp.ni.com/support/softlib/labview/labview_runtime/
-
LogMAN's post in Update values to the database was marked as the answer
I can only guess based on the help, since I generally use pure SQL syntax... The update statement will try to update all columns in your table which is impossible as you need a primary key (a column that is the unique identifier). This would be 'speedo_ok' in your example I guess. You could now either update element-by-element using the condition input WHILE speedo_ok={speedometer values.select} where you have to replace {speedometer values.select} with the actual value of the particular element. The second option is to present a new primary key to your table that is set to auto-increment; and always define the column names for your cluster whenever you use the cluster to insert / update / etc...
The update statement with all cluster elements makes no sense as far as I understand, as this would cause all rows to carry the exact same information for each column. As I mentioned before, you need a primary key that is unique. Try to update a certain element of your cluster using the condition I mentioned before.
Maybe someone else could give an actual example how to solve this based on the DB VIs?
No problem, I had to learn all that stuff too
A good source for SQL has always been http://www.w3schools.com/sql/ or MSDN of course for MSSQL.
Just for my own satisfaction , but this would be the SQL syntax (I did not test it, but it should work): You have to replace all elements in {} by their representatives in the cluster. Green would be valid, red is what you try to do (I still assume speedo_ok is your primary key):
UPDATE speedometer SET speed={max speed}, frequency={speedo max freq}, amplitude={speedo amplitude}, pulse_rev_n={speedo pulse/rev}, ratio={speedo ratio}, pulse_type={pulse type} WHERE speedo_ok={select};
UPDATE speedometer SET speedo_ok={select}, speed={max speed}, frequency={speedo max freq}, amplitude={speedo amplitude}, pulse_rev_n={speedo pulse/rev}, ratio={speedo ratio}, pulse_type={pulse type};
I hope that helps.
-
LogMAN's post in ADO Error: 0x80040E09 (or) -2147217911 in DATABASE Toolkits was marked as the answer
Your example should create a table with 2 columns (1x Numeric & 1x Text). The table name is '123' and will have 4 rows ( 1|abcd, 12|abc, 123|ab, 1234|a ). I'm not sure what you are trying to archive with it. Anyways, here is my example (did not test, but it should work if you open the database properly):
If I'm correct, the database should get a new table 'fancy_table' with three columns 'column_1', 'column_2' and 'column_3'. The table should also contain a single row with data ( 'first column' | 'second column' | 'third column' ). The maximum text length for each column is 50.