control-drag object (SQL statement) allow last select hold

[EngrStudent]

I'm making an SQL statement using the SQL library, but I'm sure this is a LabVIEW and not an SQLite idea.

I have this when I drag down on the "bind parameters".

Each time the drag downwards it goes to a different "bind". 

I want to connect a big stack of integers.

I wish that I could control-drag and get whatever the last one was to stay the same.

[AristosQueue (NI)]

Normally, it makes no sense to write multiple times to the same property. It's a pretty unusual situation, since secondary writes overwrite the previous value. It implies that the property has side-effects beyond just setting the value. It sounds like your bind is an API where you have a *property* where every time you write to it, it binds a different thing. Is that correct? That's very unusual.

[EngrStudent]

AristosQueue,

Here is where I am at. 

It took a little time to click those ~25 things and set them up.

It is the "textbook" SQLite toolbox by Dr. DJ Powell.  I don't think it is "pretty unusual", but I don't know too many toolboxes.  SQLite is arguably the #1 database engine on the planet. 

[Intaris]

This idea is not relevant to SQLite per se.

The SQLite Toolkit you are using is provided by a third-party (and it's great BTW).  The behaviour you describe is the behaviour of all property nodes as AQ has noted.

The only thing I can think of is autofilling within Excel where if you have a clear trend in some cells, then select those cells and autofill, Excel will auto-continue the trend (I think it only recognises linear trends).  Maybe a similar approach here could help, if the last two elements of a property node are the same, then autoexpanding will create more instances of the same but if the last two are different, then is behaves as it currently does?

[crossrulz]

I am not familiar with that toolkit.  But since it is using LVOOP, the property node is really just calling a VI repeatedly.  So why couldn't you just use a FOR loop?

[EngrStudent]

@Intaris - The excel autofill is a great exemplar for the value proposition.  This is how people use cells with data.  Being able to autofill for equations or data is useful.

@crossrulz - I have a reasonably long SQL statement that these are inputs into.  If I rewire the diagram, then I have to split the statement into around 25 separate statements.  It makes things much more complex. 

This diagram is the LabVIEW equivalent of the python "executemany" to block-input into the database.  (link)

[crossrulz]

No.  You use a shift register to hold the updated statement and just autoindex on the array of integers.  Again, unless I missed something with the LVOOP property node.

[AristosQueue (NI)]

My question -- why is that API meaningful? Why does it exist? In what world does it make sense to assign a PROPERTY multiple times and have an object that is not the same as just assigning the last value of the property?

"Bind Integer" should have been a method, not a property, because it is stateful across multiple assigns. This is a clear abuse of the meaning of the word "property" -- too many side effects. I would have rejected this API from ever shipping if it had come through my desk for review. I don't think we should redesign the Property Node of LabVIEW to account for such a rare and poor use case.

[crossrulz]

Just had a chance to look at the function.  Yes, it really should be a method from a purist standpoint.  But I can see the reasoning behind the property node (mostly because there is no way to make an invoke node for LVOOP that would behave this way).

Now back to the idea...the proper way to do what you want here is to use a FOR loop.  Each iteration will keep adding to the statement when you use a shift register for the object.  And you can just autoindex as many integers as you would like.  And it will require a lot less wiring, be more scalable, and reusable.

[EngrStudent]

@crossrulz - I wish I could star that answer.  Thank you.  That is useful.

[drjdpowell]

I used the “Property Node” syntax in SQLite Library because it works so well with Parameters and Column values in SQL calls.  Like Properties, Parameters and Column values are accessed many at a time and only have one input or output (other than the standard Object and Error).  LVOOP “Properties” are implemented as subVIs, and thus aren’t strictly limited to property-like behavior.  Though it would be nice to have an LVOOP “Invoke” node that had “pull-down” ability, to be used instead.