Jump to content

ShaunR

Members
  • Posts

    4,840
  • Joined

  • Days Won

    290

Everything posted by ShaunR

  1. You can use "REPLACE" which will "INSERT" if it doesn't exist or, "DELETE" the old record and then "INSERT" if it does.
  2. Queues are good for this sort of thing. they give you inherent FIFO sequencing. You can use the "Event" structure to place the controls' refnum on the queue then replicate the changes by emptying the queue.
  3. Confidence is the feeling you sometimes have before you fully understand the situation.

  4. Indeed. You can. When you edit the pallet menus, there is an option (right click on the VI) to "Place Vi Contents". I you create a VI and set this value, the contents of the VI will be placed in the diagram instead of the icon. lol. JGCode is a faster typist than I
  5. I don't think they are any more painful than, say, queues or notifiers. My only gripe is that there aren't more built-in ones.(but that's something different).
  6. Sweet. I'll update it for the next release.
  7. An elegant solution . That's going in my snippets draw.
  8. What's wrong with using "File>>Save For Previous Version"?
  9. OK. Definitive answer. Change the "SQLite Read Blob.vi" moveblock call to "LabVIEW" (note the case...it matters!) instead of "labview.exe" or "lvrt" Let me know if it fixes your issue and I'll add it to the API library.
  10. Hmmm. This could potentially be a nasty one Open the SQLite project and Find "SQLite Read Blob.vi" Open the "MoveBlock" call library node and change it from "Labview.exe" to "lvrt" Click "OK" If it starts to search for the dll, Help it by browsing to your "/program files / national instruments / shared / Labview Run-Time / [your version] directory and selecting "lvrt.dll". Save the vi and the project. You should now be able to open your project and build the app. It may ask you again to find the lvrt.dll. If it does, so the same "browse" again as the above. I can put in a switch to detect the change between run-time and dev, but if its not automagically picking up the run-time dll, this will cause a huge headache in multiple version systems. I'll look more closely into this, but the above should enable you to build your app until I find a better solution.
  11. You're right. In my quick scan of the examples I assumed that identifying which ones had changed was also a requirement. If it's only the number then it should count them OK.
  12. You can use the "Order BY" in the where clause. e.g Note that you have to have a where statement of some description so you can use RowID>0 to return all rows in a table if you have no "Where" constraint.
  13. It beats the cr@p out of Labview for web services But my response was to the question "what other languages do you use".
  14. Because his example only updates and checks when there is a change in data. Your version (without the event case) continuously evaluates the difference between the current and previous values so you miss the change. By the time you press the stop button, the previous and current values are the same (although different from the starting values) therefore you don't detect a difference.
  15. IC. Yes I tried that and didn't notice much of a change, but then again 3% on 40ms is only about 1ms which is in the noise level. I would have expected more, But it seems DLL call overhead is virtually non existent when set to a subroutine. IF I ever write a manual. I will If you don't use execution systems and/or priorities, then you are limited to 4 threads (+1 for the UI). I don't think most people worry about it (LV is very good t making things appear to be very multi-threaded), but with very IO oriented asynchronous designs,it improves performance immensely (if used correctly). ThreadConfg.vi is my favourite VI I'll keep it in mind for now.
  16. Nope. We've wanted the ability for years(along with control creation at run-time). We got xnodes instead (a compromise).
  17. Delphi, PHP, and (when I'm dragged kicking and screaming like a 5 yr old girl being chased by a great white shark ) C/C++
  18. Thats about 3% which is hardly worth the effort (although I'm not sure what you mean by modifying.....in-lining?) If I in-line the VIs I get exactly the same performance for insertions as you. But slightly slower on select (only gaining about 5ms in the 10,000 test) That won't happen. I use a high priority but in a different execution system and therefore force LV to run the queries in a different thread from the users application (assuming the user isn't using the same execution system of course). It basically forces a high priority thread rather than VIs which should mean it gets a higher priority on the scheduler. On my machine I always run with the maximum number of threads (~200) since a lot of my systems use asynchronous tasks at various priorities. This is the way things like VISA work Although I did notice it is set to "Standard" and should be set to "Other 1" (not quite sure how that got changed). I did look at it. But found that I needed to check the error every dll call and extract the string if need be. So I went for passing the error code up the chain and converting it at the end. Indeed. Missed that one.
  19. You can use the "Toggle" or "Change to Control" properties for this. http://www.screencast.com/users/Phallanx/folders/Jing/media/6d33f01c-4961-4c88-9944-e3290ab349a0
  20. Excellent. So my "improvements" are indeed improvements. I think we are getting to the stage where implementation is becoming the major difference. Obviously my version uses a much deeper nesting since I prefer a modular decomposition (and have abstracted further) as opposed to (say) putting many DLL calls in one VI - which would save the sub-vi overheads. But for the sake of performance vs maintenance that is acceptable (to me at least). I would also expect you to be squeezing a little more by using the 2010 in-lining feature (if you are not, then you should be) which is unavailable in 2009. But I take note of your suggestion to promote the get_column_count which (in theory) should skim a ms or two of the time (does't seem to make any noticeable difference on my machine though).
  21. Yes and no I like the encapsulation so that If I decide to expose the "Bind Execute" into the Low Level palette, then the user would not have to worry about it. I'm not sure (now) if bindings are persistent or not across opening and closing the DB (I originally thought it was persistent) as it is not stated anywhere and when I checked I couldn't discern any difference in performance. So just erring on the side of caution really. When I run out of things to do, I might look at it again (if I remember ). Have you noticed any improvement in performance between this version (1.2.1) and version 1.1?
  22. An empty array is slightly different. Since I use self indexing for loops, the bind never gets executed. However. I've just noticed that the classic problem also occurs. The sql ref and the DB ref are passed as "0" to the Bind Clear meaning they never get freed. Whilst his is obviously undesirable, I would have expected SQLite to return a "Misuse" error. It doesn't Instead error 1097 occurs which isn't good (possible crash under the right conditions). I will put some defensive code around this So inadvertently you have uncovered a bug, although not the original one
  23. I thought about this a while back. Labview has no concept of "NULL" string. We can neither create it nor check for it. If we put a string control / constant down, we can only have an empty string (and any of our VIs that accept a string will have a string control). So the choice becomes do we allow a write to a NOT NULL field to always succeed (which is what will happen with your suggestion) or do we define an empty string in LV as being the equivalent to a NULL string. I think the latter is more useful. Good job I cannot take back the rep point eh?
×
×
  • Create New...

Important Information

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